[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:
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
David A. Holland
Main Index |
Thread Index |