Re: [Arx-users] Configurations (and the ArX ArX archive)

[Kevin Smith]

Walter Landry wrote:
> That was a large part of the motivation behind the "super-tag"'s that
> I mentioned earlier.  I always thought that configurations were
> clumsy.  In the meantime, if you have any suggestions to improve the
> manual, I'm all ears.

Ok. if the "config" command is going away, then I'll just focus on 
improving the docs. If the command is going to stay, then I have a 
suggestions for making it friendlier (see below).

The most important thing in documenting config is to provide a context. 
What the heck is the purpose of this thing, and what is the basic mechanism.

If I understand it, a project can have one or more "config" files, each 
of which define a set of other related projects. You refer to that main 
project as the "superproject", but it can still be a normal project, 
too. By convention, the config file(s) would be stored in a project 
subdirectory named "configs".

The user can use the config command to overlay those other projects into 
the current workspace. There are "get" and "merge" options available, 
which correspond to the arx commmands of the same name.

After that basic introduction, I would give the example from ArX. But I 
would show the commands first, and only then show the arx.arx contents.

If that sounds reasonable, I think I could take a stab at actually 
rewriting section 5.5. Let me know.

If the command is not being phased out soon, I would suggest splitting 
it into two commands: config-get and config-merge. This avoids the 
confusion of having certain options only apply to one or the other, and 
also allows them to more closely map to the main get and merge commands.

Also, I think "config" is a poor choice (even though I can see where it 
came from). I think it should be something more descriptive like 
multi-get or overlay-get or subproject-get, or something like that.

I notice you have a bug in the tracking system to change the way config 
is handled. If I understand that change request, it would create the 
concept of a "superproject" that would NOT also be a normal project--it 
would just be a shell...kind of like the multi-tag we discussed. I like 
that direction.

Kevin