[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dustin Sallings
Subject: [Gnu-arch-users] Re: {arch} directory
Date: Wed, 24 Sep 2003 09:46:21 -0700

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]