Comparison with Git, Mercurial or Darcs?

[Stephen J. Turnbull]

Ben Finney writes:
 > Daniel Carrera <dcarrera at gmail.com> writes:

 > I've never seen a good explanation for why it would be desirable
 > for anything involving a repository that might ever be shared with
 > anyone -- and I think it's folly to decide forever that any
 > particular repository will never be shared.

Huh?  The operative constraint is that you don't do DAG surgery on a
branch *after* that branch has been shared.  Until then, there's no
problem.  So when I want to share a repo that I do DAG surgery on, I
make a copy.

 > You're not describing an "oops"; you're describing an unexceptional
 > "develop a feature in parallel with other development" workflow, which
 > in Bazaar is done by making a feature branch to explore the parallel
 > development of a feature. At any time (i.e. whenever you decide it's
 > time to do so), you can merge back and forth between one branch and
 > another.

That's one way of doing it, but it's not the only way.  Even Robert
and Aaron (the developers of looms and pipelines, respectively) agree
on that.

 > > I must be confused, but I would have thought that any distributed VCS
 > > can act like a centralized VCS if you choose to use it that way.
 > 
 > No, a centralised workflow implies that the repository is in a central
 > location, and is the common commit location for numerous working trees
 > (used by multiple people, or multiple distinct machines by the same
 > person, or both). AIUI most DVCSen can't do this.

For values of "can't" == "requires a two-line shell function."

With that off my chest, let's say that bzr's support for this is
complete and robust.  It turns out that there are actually a fair
number of different centralized workflows.  For example, you can have
one repo and a checkout, where a checkout is a working directory with
Bazaar control files but no revision data (except for the version in
the working files).  This mode of working leaves you with the usual
constraints of always being up to date before committing, etc.  (This
cannot be exactly implemented by git or hg, but I would not want to
anyway.)

Alternatively (what you would have to implement for git or hg with
that "two-line shell function"), you can have a central repo and local
repos with "bound branches".  That means that you do keep revision
data in the working copy, but every commit automatically implies a
push to the central repo.  You now have a choice of behavior in the
exceptional case where the commit succeeds but the push fails.  You
can  rollback the commit (but not the working changes!), update your
local copy from the central repo, and try again.  Alternatively, you
can merge the new version from the central repo into local and then
commit that merge, which is automatically followed by a push.  Most
people think the former mode is cleaner.  What you get for this
complexity is the option of working off-line, and creating local
branches cheaply.

Bazaar supports *both* of those modes (but not at the same time in one
working copy, of course!) cleanly and robustly.  And they look
(almost) the same as the workflows you get when using bzr-svn on a
Subversion repo.