Date: Mon, 7 Feb 2005 10:16:38 -0800 (PST)
From: Tom Lord <lord@emf.net>
Message-Id: <200502071816.KAA07437@emf.net>
To: cameron@patrick.wattle.id.au
In-reply-to: <20050207172401.GA21260@patrick.wattle.id.au> (message from
	Cameron Patrick on Tue, 8 Feb 2005 01:24:01 +0800)
Subject: Re: [GNU-arch-dev] Re: GNU Arch status update
Cc: gnu-arch-users@gnu.org, gnu-arch-dev@lists.seyza.com
Precedence: list
Sender: gnu-arch-dev-bounces@lists.seyza.com
Errors-To: gnu-arch-dev-bounces@lists.seyza.com
Status: RO
Content-Length: 4650
Lines: 102

Replies:

I've noted in `commit-signature-crash' your more detailed elucidation
of the original report ("fails, crashes and burns horribly").

   >    tla tag:
   > 	   - default the '-S' switch to on
   >    tla import:
   > 	   - default the '-S' switch to on

   > Can you think of a different request that would satisfy you instead?

   > Those changes would lower the barrier to allowing simple typos to
   > muck up an otherwise perfectly clean archive and so I have not created
   > a bug report for them.

   This claim cropped up last time making -S the default was suggested,
   but it seems a bit odd to me, for a couple of reasons.  One is that I
   almost alwasy type 'tla tag -S' or 'tla import -S' rather than just
   tag or import; so making -S the default would simply save typing
   time.  The other is that you've got to type the revision name when you
   run archive-setup by hand anyway, and I'd have thought that the
   probability of making a typo there would be the same as making a typo
   when running tag/import.

It's not the common case that such safeguards are there for -- it's 
the exceptional but forseeable case.   For example, there's the case of
of executing a command line where the string `import' occurs where `commit'
was intended, without specifying a target archive explicitly.   There's 
a nice way to smudge your default archive, for example.

There's a bit of a "design philosophy" at work here:  arch tries damn
hard to stay out of a programmer's way.  The `tagline' tagging method,
in spite of the ugly tag comments, is an example of that --- you can 
rename files freely, by any means available, and never have to run `tla'
once.

But when it comes to maintaining archives, the arch design pretends
that "archives are forever" and therefore should always be approached
with extreme caution.   I would consider it only /slightly/ over the top,
for example, if `commit' interactively queried the user forcing
him to prove he'd at least pretended to review the changes being committed.
(No, I have no intention of doing that.   Though only *slightly* over the
top, it would still be *definately* over the top.)

In other words, in my view -- a little extra typing, a little extra intricacy
when it comes to an operation that changes an archive -- those are features.
That they also make it easier to make a very regular and self-consistent
CLI is just icing on that cake.

At any rate, I think that issues like whether `-S' is a default for
`import' and `tag' are judgement calls.  It's mine to make and I've made it.

Since my decision is not an entirely popular one (for very legit
reasons), I'm willing to mediate the impact of my decision in any way
practical: support for front-ends, and interactive mode (the old
`itla' idea), anything ....   You should be able to achieve the *effect*
of what you want with GNU Arch, and are invited to help figure out how
best to do that --- but I'm firm on not making -S the default for `import' 
or `tag'.


   > Are you sure that fixing `help-too-long' isn't enough to answer
   > your concerns in this area?

   Out of curiosity, do you have a particular approach in mind for fixing
   this one?  

In what sense?  I have a bunch of design ideas and note a bunch of
constraints...  it doesn't strike me as hard.

   I did a bit of work last year at restructuring the help
   into various subcategories, but it fell by the wayside a bit (I lost
   enthusiasm and found other commitments).  

It's not a technically difficult problem at all and that's why it's hard
for a third party to leap in and just do it.   There are a gazillion
straightforward approaches but only a few that can be slipped in really
cleanly and non-disruptively.   Probably I should solve it by doing it
and, so far, user feedback is suggesting it's a high priority relative
to its cost-of-solution and compared to the other bugs in the list.

   e.g. "tla import" says "archive a full-source base-0 revision" which
   while is both rather mystifying to one unfamiliar with arch, and also
   technically inaccurate (I think... pretty sure you can have import
   revisions other than base-0).

Honestly, I forget off the top of my head whether you can with `tla' or not.
You could with `larch' and you should be able to with implementations of 
`arch' but I *think* I recall not bothering with it in my rush to get `tla'
out the door.

I've started a new bug db entry, inspired by this: `review-fix-help-msgs'.

Thanks,
-t
_______________________________________________
Gnu-arch-dev mailing list
Gnu-arch-dev@lists.seyza.com
http://lists.seyza.com/cgi-bin/mailman/listinfo/gnu-arch-dev