Thu 19 Jan 2006 03:02:37 PM UTC, comment #1:
To browse the current version of the sources based on this patch:
http://cvs.savannah.nongnu.org/viewcvs/ccvs/?root=cvs&only_with_tag=newtags2
Some starting points in the mail archives with previous discussion:
http://lists.gnu.org/archive/html/bug-cvs/2005-04/msg00009.html
http://lists.gnu.org/archive/html/bug-cvs/2005-04/msg00065.html
http://lists.gnu.org/archive/html/bug-cvs/2005-03/msg00104.html
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
?
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.
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.
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. I'm not as worried about BRANCH.origin since I still don't really understand why .origin is useful anyhow.
|