[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #4809] Tag extension for builtin tags
From: |
Derek R. Price |
Subject: |
Re: [patch #4809] Tag extension for builtin tags |
Date: |
Fri, 20 Jan 2006 10:11:33 -0500 |
User-agent: |
Mozilla Thunderbird 1.0.7 (Windows/20050923) |
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.
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.
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 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.
Of course, I need to make time to look more closely at your patch. This
misunderstanding is almost certainly my own failing.
Regards,
Derek
--
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 717.579.6168
f: +1 248.835.1260
<mailto:derek@ximbiot.com>