Re: [Gnu-arch-users] Re: Archives use cases

[Bruce Stephens]

Clark McGrew <address@hidden> writes:

[...]

> I can see how that would work with a project that is developing a
> small number of packages, but how does that work in a larger
> project.  Using an example dear to my heart, the superk software is
> a collection of many different packages, and a large number of the
> libraries will be needed to build any given program.

That's an interesting question, and it's one that Tom's interested in,
too---one of his visions is of a complete Unix composed of source
retrieved from revision control.

One idea (and I think it's the one most likely to work, as things are)
is to use configurations.  So basically you ignore the tla imposed
naming, and use configurations to provide the naming.  Configurations
can be named as you wish, so you can certainly use hierarchical names
for them, if you want.

Possibly a hierarchically structured namespace would be better for the
kind of work that you do.  Some other systems are using such
namespaces (subversion seems to, although I'm not sure that it's a
very disciplined use---I had the impression that arbitrary trees could
be regarded as independent entities, similarly to CVS), for example
OpenCM has such a namespace, although when it'll have the rest of a
usable distributed system is anyone's guess.  

Tom Lord once suggested he was thinking of changing arch's namespace
to a hierarchy (something like tla/devo/1.1 rather than
tla--devo--1.1, but with arbitrary uninterpreted components).  That
hasn't happened, obviously.  No reason why someone couldn't try
implementing it (one could also reduce the redundancy in paths, and
perhaps help arch on cygwin at the same time).

> Consider a hypothetical first year graduate student faced with
> several megabytes of source code, and unfamiliar with all of it.
> She has been asked to compile and run something by tomorrow so the
> results can be discussed *now*.  How is this student suppose to find
> all of the categories needed to run her program.

It's got to be a configuration or some other similar file.  It would
be the same in CVS (or would be likely to be).

> Particularly if the packages are spread over several other peoples
> archives?  A config package will solve the distribution problem, but
> the next step will be to make a change in the code.

That's OK.  The checked out tree will tell you what it thinks its name
is, "tla tree-version", and where the root is "tla tree-root".
Presuming the category/branch names are chosen reasonably (given the
limitations), then just using the same name ought to work acceptably.

> It is very helpful if newcomers are faced with a logical naming
> scheme.  Side documentation helps, but good organization is
> essential.

True.  But here there's a bit more: having got a working tree (from a
configuration, I presume), and found the bit of the project you want
to change, you can ask the working tree what it's called.  That name
might not be particularly meaningful, but in a practical sense that
ought not to matter most of the time.

> The other consideration is that although we physicists tend to work
> like a disorganized free software project, we try very hard to
> separate the individual from the code.  That's because much of the
> code is developed by graduate students and post-docs who will be
> leaving the project in a couple years; however, the code will
> survive for decades.  I think that we need a central archive (or
> small set of archives) that keep the official version of the code,
> and those archives must be structured to handle a large number of
> categories.  I also suspect that it won't be feasible to change
> archives frequently.

Yeah, that strikes me as more challenging.

[...]

> The next step is to play with it and see if I can make it work from
> a technical point of view.  I'm getting the impression that I'm
> heading into new territory as far as using tla in a largish academic
> collaboration.

I think so, too.  tla is pretty new altogether, so many people are
using it in new ways simply because they happen to be early.

> I see real advantages gained by using distributed development
> archives where each person keeps local branches for categories that
> they are working on.  The trick will be to setup a structure to keep
> the flexibility from degenerating into chaos.

Indeed.  It's such an advantage for so many areas of development that
it's surprising that (in the free software world) it hasn't been
attacked more aggressively before.  It's something that so many people
want to do: track some project that you check out from some anonymous
CVS server, and keep a local branch of it.

[...]