Re: [Gnu-arch-users] configs - extracting from arch

[Robert Collins]

On Mon, 2003-11-17 at 02:42, Robin Farine wrote:
> >>>>> Robert Collins writes:

>     > Well, I suggest you grab config-manager and play with it. Then we can
>     > discuss the pragmatic issues that arise.
> 
> OK, I did. What I see is that you solve the above problem by adding
> the root of CVS subtrees to the precious category of the parent Arch
> tree, and the root of an Arch subtree to the parent directory's
> .cvsignore file of a CVS managed tree. CM could handle this
> automatically while building a config.
> 
> Now, say you have a CVS managed tree with a subtree you work on and
> have under Arch control, while other guys working on the same project
> use CVS exclusively. They maintain the subtree you have under Arch
> control as a CVS module. So for your needs, the subtree should be
> mentioned in the appropriate .cvsignore file of the parent tree, which
> the CVS only guys probably won't like.

Right.

> For everyone to be happy, either you keep a working copy of the parent
> tree with a locally modified .cvsignore file and you never commit
> changes in this tree (you just update it), or if you need to work on
> it as well, then you will probably end up putting it under Arch
> control.

Sure.

> The same kind of problem arises in the situation where the parent tree
> is under Arch control and the subtree under CVS control. You will have
> the root of the subtree added to the precious category in the parent
> tree =tagging-method file. If I want to work on this project but with
> both trees under Arch control, then I will need to remove the subtree
> root from the parent tree's precious category. But a merge of our
> changes in the parent tree to the common branch will have to somehow
> take care of the fact that we have a difference in the =tagging-method
> file and that we intend to keep it so.

How about this though:

CVS with a non CVS nested tree foo will generate a ? foo during update
and commit. So no errors will occur. I think that leaving the arch
directory out of .cvsignore will serve CVS parented trees better. CVS
will stop automatically when no CVS subdir is found in foo.

arch with a non arch nested tree bar will depend on arch's tagging
method and regexps as you note. Now, with per dir regexps, we don't need
to consider tree wide policy, only local dir policy. What happens if you
have an arch tree with an arch tree nested, and not marked as source?

   it breaks inventory, and thats about it : tla currently has no
--nested command for most of its transactions.  (*)
   
So, back to arch with a non arch nested tree bar. arch will preserve it
if it is marked as precious as you noted above. arch *may* try to commit
it if it is marked as source, but will *need* it marked as source if
other folk are using an arch source in the same place as bar.

IOW, for an arch tree with a possible nested arch tree or non arch tree
at the same node to be happy in both states, untagged-source precious is
probably needed, as the arch nested tree will carry its id with it, and
like cvs arch will generate a 'X would be source' warning.

So what options for those folk that want this mix n match approach?
Well, I can think of two easy ones.
1) do tla init-tree --nested in the CVS sub tree's root after checkout.
Add {arch} to the .cvsignore file. This will stop tla barfing because it
will *think* it's got a nested arch tree. CVS won't commit the {arch}
'noise', and will only need the one change: to .cvsignore at the root.
Now, if someone is doing the arch metadata in CVS syncronisation
approach, this doesn't work (obviously), but if they are doing that,
then this *isn't needed* as they should just grab the arch tree.
2) don't do it. While this may sound flippant, it's not intentionally
so.
 The use of configs implies at least a minimal relationship between the
projects involved, and the parent tree has the ability to set a certain
amount of policy within itself. If 
 a CVS tree bar exists, and
 you're creating an arch tree bar and
 want to replace CVS-bar with arch-bar in your config for your arch
using users;
    update the config, tagging-method at the same time, and inform your
users. There is no need for them to stay stuck on CVS once the arch tree
has been created.

I suspect that 1) is a cleaner option all around though.

Rob

(*) side-question, for mulling over: should inventory --nested, which by
it's very nature steps outside the current tree, require that stepping
outside the tree occur at points marked source? If not, then what is
acceptable? junk (no, should be obvious), backup (no, again)... I think
the whole answer is yes, inventory does the right thing now, don't touch
it. And the reason is simple: all the categories other than source
prevent recursion, deliberately. Altering precious to be sort of
recursed into would add special cases for the hell of it.

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part