On Friday 20 January 2006 16:11, you wrote: > Frank Hemer wrote: > >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'. > > Okay. I guess I didn't scan the function correctly. It looked like it > was resolving the revision based on the revision number rather than a > tag, but perhaps I only looked at the function that resolved 1.3.2 or > 1.3.0.2 into 1.3 and tags were resolved and verified to be branches by > its caller. I'll try and make time to take a closer look later.
All symbolic tags are resolved to their numeric revision number in rcs.c: translate_tag prior to calling the fns that calculate the newtags. RCS_extract_tag verifies that no relative tags can be run on whole projects. > Well, like I said, I still don't really understand the need for .origin > in the first place. Could you provide a use case that demonstrates the > need for .origin? I have looked through the previous threads of this topic. I think the following link explains this issue: http://lists.gnu.org/archive/html/bug-cvs/2005-03/msg00101.html Another example: I have a project and want to add features I already have coded in another project. So I create a branch and add these files to the branch. When I'm finished with adaptions I merge these changes to the trunk. Now I want to review the changes that were necessary to reuse the code. Using .origin, I can cvs diff -r MYBRANCH.origin foo1 foo2 ... to see the changes or create a patch for the affected files. I even might have added these files via import or simply add; '.origin' is an easy way to address the very first version without the need to remember an import tag or to look up the revision number from cvs log. > I was just worried about this sort of case resolving correctly, but I > may not have read the code deeply enough, as with my .root error above: > > BRANCH 1.3.0.2 > SUBBRANCH 1.3.2.7.0.2 > > Since I though that only the revision numbers were being used to resolve > something like .origin, I was wondering what SUBBRANCH.origin would > resolve to with no commits to SUBBRANCH. Since SUBBRANCH resolved to > 1.3.2.7, I thought resolving it numerically might resolve to 1.3.2.1, > which is incorrect for SUBBRANCH, and suggesting that if SUBBRANCH was > resolved to its magic branch number, first, you should be able to > consitently resolve SUBBRANCH.origin to either the first commit on > SUBBRANCH or to /dev/null. This was partially in response to an old > email where you said that none of the new operators would work on > multiple files, but only on a single file at a time and it seemed to me > that .root and .origin should both at least make minimal sense when > applied to a whole project. Yes, I remember. This was at an intermediate state of development, the issues have been addressed and fixed, so it should;-) exactly behave as described in doc/cvs.texinfo. A fix for the 'MYBRANCH.origin' with no commits on MYBRANCH bug can be found in the patch-tracker. Best regards, Frank _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
