Re: VCS comparison table

[Jeff King <peff@peff.net>]

On Sat, Oct 21, 2006 at 01:11:49PM -0500, Matthew D. Fuller wrote:

> Maybe that's what you mean by 'centralization'; each branch is central
> to itself.  That seems a pretty useless definition, though.  In my
> mind, actually, it's MORE distributed; my branch remains my branch,
> and your branch remains your branch, and the difference doesn't keep
> us from working together and moving changes back and forth.  Forcing
> my branch to become your branch sounds a lot more "centralized" to me.
> 
> Now, we can discuss THAT distinction.  I'm not _opposed_ to git's

OK, let's discuss. :)

I think the concept of "my" branch doesn't make any sense in git.
Everyone is working collectively on a DAG of the history, and we all
have pointers into the DAG. Something is "my" branch in the sense that I
have a repository with a pointer into the DAG, but then again, so do N
other people. I control my pointer, but that's it.

So don't think of it as "git throws away branch identity" as much as
"git never cared about branch identity in the first place, and doesn't
think it's relevant."

Now, there are presumably advantages and disadvantages to these
approaches. I like the fact that I can prepare a repository from
scratch, import it from cvs, copy it, push it, or do whatever I like,
and the end result is always exactly the same (revids included). With
your model, on the other hand, it seems the advantages are that in many
cases you can do things like distributed revnos.

> agree on branch identity, it's completely pointless to keep yakking
> about revnos, because they're a direct CONSEQUENCE of that difference
> in mental model.  See?  They're an EFFECT, not a CAUSE.  If bzr didn't
> have revnos, I'd STILL want my branch to keep its identity.  You could
> name the mainline revisions after COLORS if you wanted, and I'd still
> want my branch to keep its identity.  Aren't we through rehashing the
> same discussion about the EFFECTS?

I agree completely.

> > 2. But the preferred git workflow is to have two branches in each of
> > two clones. The 'origin' branch where you fetch changes from other
> > repository (so called "tracking branch") and you don't commit your
> > changes to [...]
> 
> Funny, since this reads to me EXACTLY like the bzr flow of "upstream
> branch I pull" and "my branch I merge from upstream" that's getting
> kvetched around...

The difference, I think, is that it's easier in git to move the upstream
around: you simply start fetching from a different place. I'm not clear
on how that works in bzr (if it invalidates revnos or has other side
effects).

-Peff