[Gnu-arch-users] Re: DARCS

[Miles Bader]

Mirian Crzig Lennox <address@hidden> writes:
> > So you have a nearly empty wrapper directory around _every one_ of your
> > source trees?  Gah...
> 
> Why "gah?"  The alternative is to clutter the user's source tree with
> magical names like "{arch}", ",,what-changed.foo" and ++log.bar",
> requiring added complexity to tell them apart from actual source.
> Directories are the canonical way to partition namespace in Unix, so
> we may as well use them.  Let the kernel do our work for us rather
> than requiring every utility know how to recognise junk paths from
> source.
> 
> This is also the rationale behind the common practice of keeping build
> directories separate from one's source trees.

There are several reasons why I differentiate those two things (arch
clutter and build files).

  (1) Arch clutter is fairly innocuous -- there's simply not very much
      of it (typically much less than CVS, for instance), often just the
      single {arch} subdir in the top-level directory.  It doesn't
      interfere with my view of the source tree.

      Build files, by contrast, _do_ interfere quite a bit with viewing
      the source tree, simply because there's so damn many of them (and
      they typically have names that look almost like the source files,
      making things even harder to parse).

  (2) When there's extra arch clutter around (like ,,* or ++* files),
      it's usually something I _want_ to see, because it denotes an
      unusual state of the source tree.  By keeping this stuff with the
      source files, 

      Build files, again by contrast, are usually not interesting.

The .arch-ids files could be moved into {arch}, sure (though in practice
those seem to cause no problems).

As for whether you want /wrapper/{{arch},source/...} or source/{{arch},...}
there are again several reasons I dislike the wrapper approach:

  (1) An extra wrapper dir is just another bit of noise to deal with --
      and unlike {arch}-in-the-source-dir, it's one I _often_ have to
      deal with, since I type pathnames in source trees far more often
      than I do things that run afoul of {arch}.

  (2) It's an annoying little inconsistency between traditional project
      trees and CM'd project trees, and every little thing like that
      requires brain state to keep track of and changes in tools to
      account for them.

-Miles
-- 
I'd rather be consing.