Michael Gersten wrote:
> 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).
That's the gist though I think CVS only uses even branch numbers. I'm not sure
why, since I've seen it work properly on a repository created with RCS and
containing odd branch numbers (the explanation might be in the code, though I
think not the Cederqvist). The tag (say, BRANCHNAME) associated with RCS branch
1.5.2 would be associated with the CVS magic revision number 1.5.0.2. Again,
I've seen it work on a repository where branch tags were associated to the RCS
branch revision number, like 1.5.2.
> Am I missing something? Do I have the real vs magic stuff down right?
I'm not exactly sure what you mean by magic versus real. I think CVS and RCS
each have their own magic revision numbers used to specify branches. And like I
said, I think CVS can use either.
> 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).
Well, you can determine full branching order for any branch creations the file
was included in, due to the tags, so I'm not quite sure why not creating a new
revision on a branch until you commit changes is a problem, but you're right
about the rest of it.
> 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.
I think I said yep already.
> > > TRUNK - top of the trunk
> > > 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)
> > > TBASE - point at which this file left the trunk. Same as self if not on a
> > > branch.
> > > SPLIT - point at which this file left was branched. Same as self if not on
> > > a branch.
I think I like TSPLIT ("split from trunk") and PSPLIT ("split from parent")
better (your TBASE and SPLIT, respectively). Seems more consistant. TBASE
sounds like the base of the trunk to me, especially viewed alongside BHEAD and
PHEAD.
BHEAD might also be slightly redundant (you could use the branch tag instead...),
but I can see it being useful for generating scripts which don't need to be aware
of which branch they're operating on. Okay, I can see a second usage. If you
had checked out a freezepoint you could merge onto its branch from the workspace
without a new checkout/update AND without determining the branch name the files
originated from. It might almost make sense if you force-wrote some changes into
your "freezepoint workspace" and wanted to check them in, but you probably
shouldn't be force-writing changes to a freezepoint workspace. Of course, if
you'd done it by accident, cleaning up would be easier. Of course, this probably
make it easier to introduce user error into the process. Nah, this usage would
definately be redundant. You should have used a branch in the first place.
Derek
--
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
Q: What's the difference between Rush Limbaugh and the Hindenburg?
A: One's a flaming Nazi gasbag and the other's a dirigible.
