Comparison with Git, Mercurial or Darcs?

[Stephen J. Turnbull]

Daniel Carrera writes:

 > I'm trying to understand what features make Bazaar different from
 > other distributed VCS options. Can anyone point me to a reasonably
 > updated comparison of Bazaar against other distributed VCS's?

Most of the updated comparisons I'm aware of have to do with
performance, not workflow.

The big selling point for many users is that Bazaar has the best
facilities for repo-agnostic operation.  You can use bzr as a front
end to svn, git, and maybe hg repos with very little change from the
native bzr interface.  I'm not sure how well this is supported by Bzr
Explorer or the other bzr GUIs.  There is no bzr-darcs interface
though.

bzr also has a plethora of options for automating workflow.  You can
operate in Darcs-style repo = branch = workspace, or you can operate
in Subversion-style workspace checked out from branch contained in
repo.  There is some capability for git-style "multiple named branches
in one repo = workspace" (I forget the Bazaar jargon for this).  All
of these are accomplished by choosing an appropriate configuration of
repository layout (this is not hard or complex) and options in the
bzrconfig files.  Then the usual primitives (commit, checkout, push,
pull) do the right thing.

Of course there is no Darcs-like patch theory.  I wonder if you'll
actually notice that in practice, though.

 > I would also be interested to hear any personal perspectives as to why
 > you use Bazaar.

Because my upstream does. :-)

 > * General ease of use. Darcs is much easier to use than anything else
 > I've tried. Because of its amazing "cherry picking" ability (the
 > theory of patches) it is really easy to move patches around.

AFAICT Darcs' theory of patches *in practice* depends heavily on the
fact that two changes touching different sets of files don't conflict,
and on what patch(1) calls "applying with offset".  This is no
different from what is available in bzr, git, or hg.  All of them have
cherrypicking, rebasing, and patch reversion commands that work just
about as well as Darcs does in my experience, and do it one heck of a
lot faster.  Darcs may do better in some corner cases, but I doubt
that it saves enough time to make up for Darcs' general slowness.

If you think about revisions as patches, then the Darcs UI makes a lot
of sense.  It is very simple to use (cf the complexity of having
several commands, often with options, in the other VCSes where Darcs
basically has commit and revert).

However, the Darcs UI is very poor at examining history.  Basically,
Darcs does not (and cannot, with current metadata structures) provide
a way to give an accurate historical view of the commit DAG (and AFAIK
there's not even a standard way to show the patch dependency DAG).  If
you have a very linear development process, OR a "quantum" development
process (ie, like your web developer process you have a "cloud of
virtual patches" at any one time, and after a bit of experience you
decide which ones to make permanent and which to revert) that's very
"broad" in the number of patches being worked on at one time, but you
rarely if ever worry about history a few months back, the history DAG
will not be missed.

bzr shines at displaying history.  It is very good at showing you what
you've accomplished in your current branch and relating that to other
lines of development.

 > I can add patches A, then B, then C, and then remove patch A to
 > make a change.  Bazaar's "shelve" feature is similarly very
 > interesting. I just wish I had a way to upload stuff on the shelf
 > to the test server other than using rsync.

I guess you're looking for "looms" (sort of like quilt or Stacked Git
on steroids) or "pipes" (sp?) (very like Mercurial queues).  These
allow you to maintain several lines of development in a single
workspace in a very structured way, all under revision control.
Because they are under revision control, you can push to the test
server, then checkout the pieces you're interested in testing.

These are not yet standard features of bzr, unfortunately, and at
least looms are somewhat underdocumented.  However, they are quite
stable and their users are very pleased with them.