As for determining the branch origin:
Assume: I can tell what branch-tag is associated with a given file.
IF: a commit has been done on this branch, then the information is in the RCS
file. I can get the branch number; ASSUMPTION: I can go to the parent branch
number by removing the last two pieces of this branch number.
Example: Trunk version 1.5. Magic branch 1.5.1, real branch 1.5.0.1.
Committed version 1.5.1.3, real 1.5.0.1.3 (do I have these numbers right?).
Branch origin of magic 1.5.1.3 is 1.5, of real 1.5.0.1.3 is 1.5 (ok, strip 3
levels from the real).
IF: a commit has NOT been done on this branch:
THEN: The RCS file does not have information on it
BUT: The magic branch number needs to be recorded somewhere
ASSUMPTION: I can get to the parent magic branch version by removing
(1?)
piece(s) from my magic branch.
Example: Parent was 1.5.1.3, I am (magic branch) 1.5.1.3.1, my parent CVS
version is 1.5.1.3.
Am I missing something? Do I have the real vs magic stuff down right?
Yes, CVS doesn't record a new version if you don't commit. That's annoying.
That means that in general you cannot take a single file and determine the
full branching order (you need to check the entire project that it was worked
with, and even then you have some pathetic cases if branches are made on a
per-file instead of per-project basis.) It also means that if you delete the
magic branch tag, you can't recreate it (at least, this is what I remember
seeing concluded on the list a while back).
However, even if there is no real RCS version entered, there is still a tag
for the (yet to be made) branch, and as long as that tag is there, that's all
the info you need.
Michael
"Cameron, Steve" wrote:
>
> Michael Gersten
>
> > > You're right. For consistency's sake, "cvs up -C file" should get a
> > clean copy
> > > of the HEAD. I think, in general, there should be a way to specify the
> > base
> > > revision (is there a BASE alias similar to HEAD?)
> >
> > Ok, since HEAD means different things, etc, I'd like to propose the
> > following alias tags:
> [smc] BTW, there is a similar proposal in cvs.texinfo,
> but using different names, names that begin with ".", so
> as to be guaranteed not to conflict with exiting tags...but
> this might be more difficult to implement.
>
> > TRUNK - top of the trunk
> [smc] I may have a patch that does exactly this.
> I say "may", because I haven't done extensive
> testing, and I implemented it by copying the code
> for HEAD, but fixing the part where HEAD differed
> for "cvs diff". So if HEAD is broken in other ways
> besides the "cvs diff" case, then my TRUNK patch
> would be broken in the same ways. However, I do
> not know that it is broken.
>
> > BHEAD - head of the current branch (or trunk if not on a branch)
> > PHEAD - head of the parent branch (or trunk if the file split from the
> > trunk)
> >
> [smc] possible? (see comments under SPLIT...)
> > TBASE - point at which this file left the trunk. Same as self if not on a
> > branch.
> > (Essentially, base back at the trunk)
> > SPLIT - point at which this file left was branched. Same as self if not on
> > a branch.
> > (Essentially, base of this branch).
> [smc] Is this possible? When I create a branch,
> I always do something like this..
>
> cvs rtag branch_origin everything
> or cvs rtag -r some_branch_tag branch_origin
> everything
>
> cvs rtag -b -r branch_origin branch_tag everything.
>
> I once tried to figure out an algorithm for coming up with
> the revisions that made up "branch_origin" in case I forgot
> to create this tag, using only "branch_tag". I convinced
> myself that it couldn't be done...(well as soon as you say
> something like that someone will figure out how to do it.)
>
> Anyway, this SPLIT seems like the same problem, so I'm
> wondering if it's possible. I forget now how I convinced
> myself finding a lost branch_origin type tag was not
> possible in all cases... Something to do with the fact
> that CVS doesn't actually create a new revision at the
> time a branch is created, but only when changes are
> committed to that branch.
>
> [...]
> -- steve
