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

[Tom Lord]

    > From: Dustin Sallings <address@hidden>

    >   I was kind of hoping more for justifications for the design
    > [choice of using the directory name "{arch}"] than general
    > opposition.  The only justification I've heard so far has been
    > visibility, which, as I demonstrated, can easily been provided
    > with a hook and look like anything the user wants it to look
    > like.

I'm not going to try to give you a justification about it in this
message.  For the purposes of _this_ discussion, we could just assume
that it's an arbitrary choice, sure to please some and bother others
-- in a design area where any hard-coded choice would be roughly
equally arbitrary and pleasing-to-some yet annoying-to-others.

It's interesting, though, isn't it? the way that software "harmonizes"
or fails to harmonize and how that spreads and has chaotic side
effects?  Something simple like a shell deciding to use { and =
specially and an editor using +: and suddenly you have people arguing
that over 2% of the namespace of files starting with graphical ascii
characters is off-limits.

But, then, you know: not everyone feels the pain of that shell or
editor -- so it becomes a controversy and a justification for an
option or a hook so that '{arch}' can have any name at all (or one of
a handful of names -- doesn't matter much).  10 or 20 more lines of
code.

10 or 20 more lines of code in tla.   I don't know that it might do to
little scripts people might want to write to "do stuff" with arch
project trees without necessarily invoking `tla'.

I guess we'll need perl, python, ruby, emacs, make, and php modules
that implement the hooks that figure out what the '{arch}' directory
is really called in a given tree.  Oh well ... those are easy enough
to download and put on the correct path.  Not sure what to do about a
shell script that just wants to use "find ... -name '{arch}'"

Maybe, at some point, I'll be confronted with two separately imported
development lines of the same project -- each using `names' tagging --
each using a different name for `{arch}'.   And I'll want to do some
merging between these two.

No problem again: that's just a 100 or so lines added to the changeset
components of tla to treat `{arch}' specially, record the per-project
choice of directory name in changesets, etc.

Of course, if I want to write some perl scripts that manipulate
changesets in interesting ways -- aw heck -- just more modules for
perl, python, ruby, emacs, and php.   

It's only a _little_ more code, just a tiny bit... every step of the
way.

Hmm..  Here's an interesting problem.   Suppose I tar up a project
tree and give it to you.   You untar it and throw some tools at it.  
How do those tools figure out what '{arch}' is called?   I suppose if
there's only 2-3 possible names for '{arch}' it's not _too_ bad -- but
if it's an arbitrary name?

Nah.. not a problem -- you can find it by inspection and pass an
option.   Just 10-20 more lines of code to each and every command and
a few more characters on every command invocation.

Of course, we'll need some options on various scripts, too.  Hey, we
could write a perl/python/ruby module to parse the standard --arch-dir
parameter and alert the other modules we've got.

Heck, what's one more parameter, anyway.

-t