Re: [Gnu-arch-users] Re: arch's file naming scheme is shell unfriendly

[Zenaan Harkness]

> > With the "{arch} in csh" problem, the user can type a perfectly fine
> > command line manually, hit RET, and _the command will be wrong_ -- 
> > he'll
> > get a confusing error in response (or worse:  try to use "rm -rf 
> > {arch}/m*"
> > to get rid of all patch-logs beginning with "m*" in a linux source
> > tree... :-O ).
> 
>       I think this is an example of an arbitrary decision having an impact 
> on tools that are common for a user.  I mean, I got in this argument 
> when I first started using it (somewhere around a year ago), and I've 
> seen it come up a few more times and have heard that users start to 
> really like it over time.  However, I think that as the number of uses 
> grows, that becomes less true.

agree

>       A visible directory indicating an scm does not in any way help my day 
> to day activities.  I can't use it to tell whether I'm in an arch tree 
> or not, as I have some pretty big arch trees I'm not always at the top 
> of.  I use ``tla tree-version'' to tell me not only that I'm in an arch 
> tree, but which one it is.

strongly agree

>       I use tcsh, and sure it expands OK when I type ``someCmd {<tab>'' 
> which makes things a bit easier for me, but it doesn't make me terribly 
> excited that there's a meta-character in my directory tree.  I think 
> the fact that bash treats {} metas with and without a comma differently 
> doesn't make the case any better, either.

I use bash. Very strongly agree.

>       When I was a newbie, people ranted at me about how newbies drop in and 
> don't consider the massive amounts of archives out there when making 
> suggestions with this kind of impact.  I was also assured that I'd grow 

Must be considered though. But I agree that the size of arch userbase
now is massively smaller than it can potentially become.

I believe that barriers to entry, no matter how small, are significant
in their cumulative effect.

> to love { and + and , and all that.  As it turns out, I do rather like 
> the use of , for temporary files.  I've been using it in my own scripts 
> here and there to indicate a file is not a permanent product, but 
> should remain here and visible.  {arch} still seems to be a barrier to 
> entry, though.  I use arch in spite of the way things are named, and 

agree

> the deep trees, and having to replace things like tar on some of my 
> systems because the filenames within a patch are too long for the 
> version of gnutar I have to store them.

I disagree here - it actually increases my confidence in the tools and
the developers' ability to ensure correctness, that they have decided on
_specific_versions_ of the various "low level" tools. I do sympathize
with your need to have had upgrations of some tools on your specific
platform(s), however I consider that a distribution and packaging
support issue - which should not be ignored I agree.

That said I do think that W32 platform support is a significant
priority, and I believe that the plan for tla 2.0 is to do some not
insignificant work on shortening these paths, in order to significantly
improve the Windows-ability of arch.

>       If you were designing a new archive format today, would you really 
> have stuff like {arch} in it and lots of duplication leading to really 
> long path names that require tool upgrades?  There doesn't seem to be a 
> benefit here that justifies the trouble it causes.

The primary technical trouble occurs on W32 platforms. This is AFAIUI
being addressed with tla 2.0 (c/c--b/c--b--v will become c/b/v, and
possibly other mechanisms to contract the path lengths).

>       Regardless, the arch community will continue to grow, as will the 
> complaints.  I do suspect it'd grow faster if people had less to 
> complain about.

Significantly in fact, so the theory of minimizing barriers to entry
goes...

cheers
zen