Re: What a modern collaboration toolkit looks like

["Eric S. Raymond" <esr@thyrsus.com>]

Richard Stallman <rms@gnu.org>:
> Is this substantially different from CVS, or is it just relabeling?
> It sounds like `git push' is basically equivalent to CVS commit.

I have not yet studied git specifically (that's coming after I finish
the evaluations on Arch and monotone), but I believe all the modern
DVCSes handle this the same way.  In my survey paper, I'm calling
it the "commit-before-merge" model, as opposed to "merge-before-commit"
which is what CVS and Subversion do.  It seems to have originated with
monotone.

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. The sequence of changesets you
developed is grafted into the repo as a branch attached to the
revision you pulled from.

If no one else has committed or pushed against that revision, the line
of development remains linear.  If someone has, you have the analogue
of a CVS conflict -- the revision is now a branch point with two
histories going forward.  

Later, someone may do a merge operation that fuses those two branches
together again.  Thus, "commit-before-merge".

This is certainly the way monotone, Mercurial, and bzr operate.  As
I said, I have not yet studied git specifically but I'm pretty sure
it works the same way.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>