Comparison with Git, Mercurial or Darcs?

Ben Finney ben+bazaar at
Wed Nov 4 12:06:27 GMT 2009

Daniel Carrera <dcarrera at> writes:

> On Wed, Nov 4, 2009 at 7:51 AM, Ben Finney <ben+bazaar at> wrote:
> >> Ok. I guess I see your point about "darcs amend". But "obliterate"
> >> is just "unrecord and revert", which bzr can do too.
> >
> > It can, but it's not something I'd ever do except when something has
> > gone wrong in the VCS process. Instead, I'd simply fix the working
> > tree and commit a new revision.
> I don't use "darcs obliterate" just when something has gone wrong. I
> use it as part of my usual workflow.

Exactly my point: just because Bazaar *can* do a Darcs ‘obliterate’,
does not mean that a Bazaar user would do so as part of the workflow.

> When I'm working on a new feature I send a lot of small test patches
> to the test server until it works. When it works, I obliterate them on
> the server, unrecord them on my laptop, and re-record them as a nice
> set of well organized patches.

All of which would be more straightforward done as a parallel line of
development, allowing the changes to *remain* in history when later
merged, and not be obliterated. In other words, a branch.

I just don't see why there's an advantage in throwing away each of those
changes that was good enough to record in the first place, when
everything you say you're doing it for is done — better, AFAICT — by
branching and merging in Bazaar.

> If I currently share the repository with another developer who does a
> little work once in a while. I only use this features in my personal
> working branch or my test branch on the server. I find it very useful
> for my work. When a feature is complete I push it to the public branch
> where the other developer can see it, and once it's there I don't mess
> with it.

This perfectly describes a use for “feature branches” merging
opportunistically against a “trunk branch”, which from what I can gather
is the predominant means of doing what you describe in Bazaar.

> You are right that I'm not describing an "oops". You are wrong that
> I'm describing "develop features in parallel". Let me give an example:
> Suppose that to add a feature I need to add two functions to get data
> from the database and I need to change the GUI. I have to develop
> these three things together at the same time, I can't develop them in
> different branches. But when I record them in the end, I want to
> record them as three different patches.

Surely, to the extent that they make sense as independent patches, they
*can* be developed in parallel? Conversely, if they *can't* be developed
in parallel, what's the point of having them as three separate patches?

> One patch adds database function A, the next patch adds function B,
> and the last patch makes a GUI that uses A and B.

All this can be done, of course, by more branching and merging; and I've
certainly done so numerous times, and Bazaar's support for those basic
operations make it easy to keep track of where I'm up to. Without losing
history information from the end result.

> Why not [centralised repository in Darcs]? Just make a branch that
> everyone in the team is allowed to push changes to.

That's not the workflow I'm describing; that's still a distributed
workflow. What a centralised workflow does is it ensures that *every*
commit on a particular branch, by *anyone* using that branch, will be in
sync with the central repository.

> Every time a team member wants to make a change, pull the latest
> changes from the central branch, add your own changes, and push them
> back to the central branch.

A centralised workflow makes the last step automatic and non-optional.
Adding (committing) changes automatically puts them in the central
repository, as the *first* place they go; and if the branch isn't
up-to-date, you can't commit until you've resolved the issue locally.

This is useful for, say, the “master branch” that represents the merge
target of everyone in the team. I also use it for a branch that I want
to have multiple copies of on different machines (e.g. a repository of
personal documents or user config files), but ensure that no conflicts
ever get committed between two of those machines.

Of course, the great thing about Bazaar's implementation of this is that
I can have as many *distributed* branches from these in which to do my
work without bumping into any others — and merge back into the central
one when I feel ready. Moreover, I can turn any branch from one state to
the other at any point I choose; it doesn't need to be decided ahead of

In other words, imagine the centralised assurances of Subversion, but
only when you choose them; and without the bondage.

 \         “I think a good gift for the President would be a chocolate |
  `\   revolver. And since he's so busy, you'd probably have to run up |
_o__)              to him real quick and hand it to him.” —Jack Handey |
Ben Finney

More information about the bazaar mailing list