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

[Frank Hemer]

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