Linus Torvalds wrote:
I'm not 100% sure this is appropriate, but in general, I think "<rev>" and
"<rev>.1" should be considered the same thing, no? Which implies that
"1.1" and "1.1.1.1" are all the same thing, and collapse to just "1", ie a
zero dot-count. They are all the same version, after all, no?
Hmmm. I'm not sure about this. Given x.y.z.q... the 'odd' nodes
(starting from x = position 1) represent branches, not revisions, and
don't refer to actual concrete objects (just tags if you will) in the
cvs world.
So if <rev> is something like x.y then x.y.z would refer to the 'z' branch.
Furthermore, 'z' better be an even value 2 4 6 etc. because those are
the only branch id's cvs will create. The odd values are for 'imported
source' branches.
The reason 1.1.1.1 exists is some lame-ass crap that CVS delivers to any
developer who imports his/her initial source code.
It creates 1.1 as a placeholder, and I think in this special case it has
the same contents. It also creates a .1 'import branch' then puts the
imported revision onto that 'import' branch.
In a normal situation, you have rev = x.y
You branch, it 'registers' a branch x.y.z where z in {2,4,6...} (and
uses a special 'magic branch' syntax x.y.0.z in the symbolic tags
section).
Only when you commit your first change does it create x.y.z.1.
So we have:
x.y != x.y.z.1 for sure, in the general case.
Also x.y.z will never be x.y.1 for a user created branch because z must
be even number (except for import branches), in any case x.y.z is never
an actual file revision. Now, it COULD be the fact there there needs to
be special handling for x.y.z where z == 1 because that is an import
branch and something devilish is happening there.
I honestly don't know...
David
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html