Re: What a modern collaboration toolkit looks like

[Stephen J. Turnbull]

*sigh*  And I just finished writing a private message saying I didn't
want to get involved.

Eric S. Raymond writes:

 > CVS and Subversion try to maintain a linear version history unless you
 > do explicit branching.  So when you commit a change against an out-of-date
 > revision, they raise a conflict; you have to merge news before being
 > allowed to finish the commit.
 > 
 > In modern DVCSes, a push never blocks.

I think you've typoed "push" for "commit".  Specifically:

This conflicts with Mercurial terminology.  *commits* never block in
Mercurial.  *Pushes* do, unless you use "hg push -f" (which creates an
alias-less head in the target repo---its only names are the revno and
the hash).

I suspect what you meant to say here is that "In a modern DVCS, a
commit never blocks".  The reason that "commit" blocks in CVS and SVN
is because in those VCSes "commit" can be considered equivalent to a
Mercurial "commit + push".  Ie, CVS and SVN commits can block because
pushes always can block, and every commit implies a push.

Proliferating new heads in the public repo is antisocial; that's what
local repos are for.  Unfortunately, (loosely speaking) CVS and SVN
don't support local repos, so there's no way to separate commit and
push for most projects.  If the push blocks, the commit must do so.

 > This is certainly the way monotone, Mercurial, and bzr operate.

If "push" wasn't a typo, please recheck your information on monotone
and bzr, too.  I find it hard to believe that they silently allow
pushes to succeed when they would create new heads; this is a recipe
for disaster.

 > As I said, I have not yet studied git specifically but I'm pretty
 > sure it works the same way.

Like Mercurial, git blocks if you try to push a branch to a ref which
is not a prefix of the branch you're pushing.

Unlike Mercurial, "git push -f" just does what you tell it to do (push
a bunch of objects and set the ref to the same commit as HEAD points
to locally), and therefore will create garbage (lost commits and their
dependent objects) in most cases.  It does not create an implicit new
head (which can have no reference except its SHA1, and thus is pretty
useless).  Neither behavior seems particularly useful to me.

BTW, to be honest, I think "commit-before-merge" is a good advertising
slogan, but it doesn't promote understanding of how dVCSes work, and
only offers the GUI/CADT/IRC/XP view of their advantages.