Martin Roehrig writes:
[smc] my words:
> > HEAD as described here definitely has some impossible
> > or at least meaningless cases: for instance, a sticky,
> > non-branch tag (or date or revision) on a file could
> > match a revision that is present on multiple branches,
> > so which is the "correct" current branch for which the
> > tip revision should be found? There's no sensible answer.
>
> Pardon me if I ask a silly question, but how could a single revision be
> present on multiple branches? As far as I understood the revision number
> exactly defines where the revision belongs to, doesn't it?
[smc] When you first create a branch, no new revision is created,
so if you create mulitple branches, it's possible (very likely
actually)
that at least some of the files won't have changed on either branch
and thus the same revision is used on both the branches.
It works because a branch tag records a "magic" revision number
with an extra zero inserted. So if you create a branch off the
trunk
with foo at revision 1.7, say, then the branch tag will point to
revision 1.7.0.2 of foo (which is non-existent, BTW), and the
next branch tag would point to 1.7.0.4. (the ending numbers
go up 2 at a time for some reason.)
Until a revision was actually committed to those branches,
any refrence to the branches would "magically" fetch foo 1.7.
If a revision was committed to branch 1.7.0.2, the revision
number would be 1.7.2.1 (The zero is removed, and ".1" is
added at the end.) At that point there would be a unique
revision associated with that branch. (I hope I haven't botched
this explanation. The essence is correct, the details (revision
numbers) may not be _exactly_ right...)
(Hmm, lately I'm not getting any
mail from info-cvs...I wonder if that's a mailing
list problems, or if somebody here,
in their infinite wisdom, has decided
to block mail from info-cvs.
