Pushing after merge considered harmful

[Stefan Monnier]

Thanks Eli,

> Traditional, centralized version control systems, such as CVS or SVN,
> do not have integral support for branching and merging.  They consider
> the history of a package as a linear sequence of revisions:

This is an over-generalization.  RCS, CVS, Svn, and many more
centralized VCSs support branching and merging.  The main difference is
that DVCS use branches more extensively and for that reason need to
provide good (better) support for branching and merging.  I.e. the basic
idea is fine, but you'll be better off toning down your statements to
something like

   Traditional, centralized version control systems, such as CVS or SVN,
   only use branches in particular circumstances and often provide
   somewhat limited automation for branching and merging.

Now, clearly this doesn't connect nearly as well to the rest of the
text, so it would require more changes to the subsequent text.

> A DVCS makes all this much easier by tracking branching and merging
> between revisions in the repository.

Many centralized systems also do that.  The only relationship between
the two are:
- recent VCSes provide merge-tracking and that all DVCS are recent.
- DVCS use merging and branching a lot more extensively and would
  hence largely be unbearable without merge-tracking.

> To track branching and merging, a DVCS needs to be built around a
> proper representation of the relations between revisions in the
> repository.  In contrast with traditional VCSs, a DVCS can no longer
> represent the history as a line, it needs a non-linear representation
> that can express branching and merging of revisions.

I think you might just want to drop all this DVCS-vs-(non-D)VCS since
most of what you say actually also apply to (non-D)VCSes, even if some
of them don't really support that internally for one reason or another.
And in the end, it doesn't really matter whether it also exists in
(non-D)VCS.


        Stefan