Re: [patch #4809] Tag extension for builtin tags

[Frank Hemer]

> Finally, I'm not sure we resolved all the issues regarding .root & .parent.
> I'm not even sure we discussed them all.  What happens, for instance, when
> a checked-out branch looks like:
>
> file1 1.3.2.1.2.1
> file2 1.9
> file3 1.76.6.3.2.1
> file4 1.102.6.9
>
> Assuming that MYBRANCH is attached to:
>
> file1 1.3.2.1.0.2
> file2 1.9.0.8
> file3 1.76.6.3.0.2
> file4 1.102.6.9.0.2
>
> Does MYBRANCH.root return:
>
> file1 1.3.2.1
> file2 1.9
> file3 1.76.6.3
> file4 1.102.6.9

This is expected behavior. I didn't test with exactly this setup, but I did 
some very similar tests to verify this.

> Looking at your implementation, I can only say it might without testing,
> but your implementation looks much too mathematical.  With the simple
> restriction that `.root' may only be applied to named branches, which I
> should think would be the most useful application of .root anyhow, simply
> looking the branch up in the symbols table and de-magicing the revision you
> find should yield the above result.  Anything else lacks determinism with
> files that may not have been checked in on a branch.

This actually is the way it works. Except for that it is also possible to use 
the branch number. You cannot run '.root' on a whole project - this is what 
the doc says related to absolute/relative tagging. You need an absolute 
starting point in this case, which would be provided by specifying 
'BRANCH.root'.

> I think your .origin implementation may have a similar lack of determinism
> when dealing with subbranches (what's the result of MYBRANCH.origin when
> MYBRANCH is a sub-branch or YOURBRANCH with no commits?) and a similar
> restriction to working with named branches would simplify the
> implementation.

Hmm, '.origin' resolves to the very first revision. It doesn't matter if 
MYBRANCH is a subbranch. If you start with 1.1, do some commits, create 
YOURBRANCH, do some commits, create MYBRANCH and do some commits, it will 
resolve to 1.1. If any of the intermediate branches have no commits it 
doesn't matter.
If a file is separately added on trunk and a different version on a branch, 
its x.x.2.1 version will be dead - created by cvs. In this case calling 
'.origin' on the x.x.0.2 branch will resolve to x.x.2.2 as this is the very 
first version on the x.x.0.2 branch.
I will have to fix 'MYBRANCH.origin' as it currently resolves to /dev/null if 
there are no commits on MYBRANCH. This only applies to the branch where 
'.origin' is called on, all intermediate branches are handled correctly.

> I suppose it would be okay to leave the current implementations in place
> for when the .root and .origin are requested for a single revision of a
> single file, but I think the BRANCH.root implementation is important.

As I stated above, BRANCH.root should be fully functional. If there are any 
bugs, I'm going to fix them. Actually the cvs.texinfo - section 'Tags 
(builtin)' _should_ properly explain the behavior, it is a summary of our 
discussion we had before I started the implementation.

Frank