[tlug] VCS comparison [was: bash and grep and diff]

["Stephen J. Turnbull" <stephen@example.com>]

Josh Glover writes:

 > Honestly, I found Perforce as easy to work with as SVN, but I never
 > had the need to do much exotic merging.

Wel, I would expect that the best commercial centralized VCS would be
at least as good as SVN.  (Heck, it could easily be Subversion, since
the Apache license used for Subversion is permissive.)

 > One definite weakness was trying to integrate changes between
 > unrelated branches was incredibly hairy (where "unrelated" could
 > mean two separate branches off the same mainline). Git, as I
 > recall, handles this case just fine.

Subversion would have similar problems, at least through the 1.5
series, and the improvements to 1.6 are alleged to be marginal; a real
history-sensitive merge function needs to wait until 2.0, IIRC.

Actually, it's a function of what's in the unrelated branches.  For
example, if the unrelated branches touch completely different sets of
files, then there will be no problem because a three-way merge will
work fine.  On the other hand, if they touch the same line in the same
file in different ways, all existing VCSes will report a conflict.  If
you have a lot of those, you will have a hairy merge, in any VCS.
Most open source distributed VCSes will automatically merge a change
which appears identically in the branches being merged, although this
is in theory a bug.

It is possible to have a really hairy merge conflict in git as well,
and if you had "incredibly hairy" merges in Perforce, they'd be hairy
in git, too, I suspect.  What git does that nothing else does as well
is allow you to execute a complicated merge in stages, "cherrypicking"
specific sets of changes that cause easy-to-untangle conflicts (often,
no conflict) until you get to the point where the rest can be merged
easily.[1]  It provides tools (rebase) and kludges (replay-recorded-
resolution) to make this process incredibly efficient in the hands of
an expert.  What this also means is that in git it's possible to have
a workflow where integration is pretty much continuous, and as Pier
pointed out, this helps a lot.  (Whether you have such a workflow or
not is a matter of policy and managerial implementation, of course.)

Darcs has similar editing capability (and in fact can do most of the
reordering automatically -- replay-recorded-resolution is unnecessary
in Darcs), but darcs is ahistorical, really.  If keeping the history
of changes straight is important, then Darcs is not for you.

Core hg is easier to learn in almost all workflows than git, but doing
many manipulations that git implements as first-class operations in hg
can require poorly implemented add-ons and knowledge of hg internals.
hg also implements named branches poorly IMO.

Bazaar provides many of the basic alternative merging strategies as
named options to the merge command, but I find it really confusing and
poorly documented.  People who find that one of the standard bazaar
workflows work for them love it, though, because it feels like it was
designed for them personally.

Darcs and bazaar are both significantly slower than hg or git.  Fans
of those VCSes don't mind at all because they are fast enough in the
specific workflows they use, and they present a small number of
commands that do everything needed.  People who have drunk the git
Kool-Aid, though, are frustrated by the delays, and really miss the
ability to manipulate the history DAG and workspace in powerful ways.


Footnotes: 
[1]  The other thing that git does better than anything else is allow
you to create new history based on existing history.  For example,
suppose you always commit before going to lunch, or, like I do
sometimes, you set up your editor to commit on every save or every
explicit save.  git allows you to excise those commits as irrelevant
to the history management wants to see.  The result is *new* history,
not a rearrangement of old history.  git also allows you to reorder
commits; for example you may discover late in the process that you
need to make an API change to properly implement a feature.  Often
enough the API change is desirable on other grounds.  git allows you
to make the API change first, push it immediately, and let the feature
itself mature at its own pace.