tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: git branches (was: Re: Reply to David Holland's notes and comments)



On Wed, Jan 14, 2015 at 12:10:25AM -0500, Eric S. Raymond wrote:
 > >  > However, I note that CVS doesn't handle branches this way either.  In
 > >  > CVS, as in git "a branch is a self-moving tag that names the head of the
 > >  > branch, that is, a branch is a version.".  There is nothing else there.
 > >  > The same is in effect true of SVN, though the details are odd and
 > >  > slightly different.
 > > 
 > > This is absolutely not true. In CVS, when you create a branch, it gets
 > > a version number that refers to the whole branch (a version with an
 > > odd number of components) and all commits on the branch are numbered
 > > using that as a prefix.
 > 
 > Aha.  I see.  You're identifying "the branch" with its CVS prefix;
 > I'm identifying it with its name, the sticky tag on the end.
 > Terminology problem.

No, it's not a terminology problem. First, the tag isn't on the end:

   % cvs log Makefile | grep netbsd-5:
           netbsd-5: 1.262.0.2

This number (which does not change over time) tells me that netbsd-5
was branched from version 1.262 of this file, and that the commits on
the branch are numbered (in order) 1.262.2.*; it does not label the
branch head or tell me where the branch head is. For that I have to
look for the highest-numbered 1.262.2.* commit.

Second, it's a semantic difference:

 > The trouble with noticing that branch prefixes correspond to a unique 
 > coloring scheme is that it doesn't help us in any way.  We already know
 > we can induce a unique branch coloring (in fact, the same one) just from
 > knowing which the oldest branch at any junction is.

We don't need to induce a branch coloring; we already have the branch
coloring, it just requires recording the mapping 1.262.2.* <->
netbsd-5. All the 1.262.2.* versions should be recorded on the
netbsd-5 branch, and hey presto, we have the branch metadata we need
for a correct conversion to Mercurial. Or Subversion, or Monotone, or
anything else other than git.

(And third, there's a 1-1 mapping between branch version prefixes and
branch names in a non-corrupt ,v file.)

 > > So how is full branch metadata supposed to be recorded in the
 > > fast-import stream? You said above that it wasn't supported.
 > 
 > It isn't.

Ok, so it doesn't work then. So, why is the git-fast-import format so
wonderful?

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index