"Derek R. Price" wrote:
> 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.
Magic branches are the cvs tags that you give to the -r options of CVS. Real
branches are the real underlying revision numbers in the RCS file.
>From what I understand, a real revision isn't recorded in the RCS file until
you commit something on that branch, while the magic branch numbers are (as
they are nothing more than tags).
> > 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.
Lets say I have a big project. Lets say also that it was always checked
in/out as a full project. Lets say it has a bunch of branches, each created
to solve a problem, and then put back onto the trunk. Lets say that sometimes
two different such branches were active at the same time, but none of these
had edit conflicts (each was altering different files).
Now you have a heavily modified project. No single file has been modified in
every branch. But you want to (somehow) get the list of "project branches" --
what versions branched from what original versions, nestings (if any), etc.
If you look at any one file, it won't be able to tell you the branching
orders if changes weren't made to that file. (If I'm wrong here, tell me)
To find out the full history of the branches on this project, you have to
examine lots of files, each of which has only a small (overlapping,
hopefully) piece of the puzzle.
> > > > 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.
exactly what I was thinking of.
> --
> 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.
