[Gnu-arch-users] Re: {arch} directory

[Dustin Sallings]

On Wednesday, Sep 24, 2003, at 01:59 US/Pacific, Miles Bader wrote:

> Dustin Sallings <address@hidden> writes:
> > I have to imagine this has been discussed, but is there a good reason
> > to keep the arch stuff in {arch} vs. something like .arch ?  {arch} is
> > a little difficult to deal with.
>
> Why?
>
> I was a bit bothered by {arch} at first, because it was unfamiliar, but
> that didn't last long.  On balance, it seems a pretty reasonable 
> choice;
> the funny format makes it unlikely to conflict with existing
> files/directories, and it's otherwise fairly unobtrusive (more so than
> all UPPERCASED names).  I think it's actually a _good_ thing that it's
> user-visible, because it tells you something important: `This source
> directory is being handled by arch.'
>
> The only really annoying thing is that it gets hit by recursive
> finds/greps/whatever -- but so does every other in-directory solution
> (CVS, .svn, etc).

	Well, I can ``grep string *'' and miss a dot file.  In fact, this is a 
problem when importing an existing tree with a bunch of stuff at the 
top.  I want to do a ``find *'' but that matches {arch}.  I end up 
doing a ``find [A-z]*'' which is slightly less fun to type.  Same thing 
when grepping, finding later, etc...

	Also, when I want to edit something in there, it's slightly less 
convenient for me to type, ``vi ./\<shift>{[tab]'' than ``vi ./.a[tab]''

	User visibility I don't think is as important.  I know what stuff is 
handled by arch because I keep my sources in a tree I can manage.  I 
have more of a problem typing ``tla'' when trying to check stuff into 
perforce anyway.

	However, I'm still capable of using tla in directories below the top 
where there is no {arch} directory, but the tree is handled by arch.

>  (1) Some editors (vim) have problems with `+' prefixed filenames, 
> which
>      is mainly a problem for editing log-files made with `tla 
> make-log'.

	This one doesn't bother me too much...I've pretty much programmed my 
fingers to type ``vi ./+[tab]'' at this point (somewhat similar to what 
I was complaining about above, but with fewer keys that I hit more 
frequently).

	However, I wonder how much of this could be avoided by having commit 
create a log and present it with $EDITOR if one doesn't already exist.  
This seems like it could improve workflow, or at least is better than 
an error telling you to do it yourself.

>  (2) Interaction with shell completion -- bash won't complete past an
>      `=' (because it tries to support variable assignment completion),

        No interest in using bash.  :)

--
Dustin Sallings