Experiences with Bazaar in a Commercial Environment

Ben Finney ben+bazaar at benfinney.id.au
Mon Feb 20 20:57:16 UTC 2012

"A. S. Budden" <abudden at gmail.com> writes:

> Apologies for the long email...

Thanks for taking the time to make your thoughts comprehensible.

> We have been using Bazaar as a version control system at my workplace
> for the last two years. As of today, we have decided to gradually
> migrate from Bazaar to Mercurial, so I thought I would write up some
> of our experiences and the reasons for this change in case it's of any
> interest to others.

It is, and you've done well to make this a constructive analysis of the

One confusion I found:

> Could have overcome with some effort:
> 5.  Merges get intertwined with commits.  This was very frustrating and
>     probably our fault for using checkouts rather than a proper
>     distributed model.

I don't know quite what you're saying here. A merge is distinct from a
commit: one is the action of altering the working tree, and the other is
just the regular commit to VCS.

>     When you go to do a commit, if your working directory is out of
>     date with the server, you update and Bazaar merges your working
>     directory with the server state.

Why do you update? If the tree has changes that are not yet in the
branch, you don't want to update: you need to make a decision about the
uncommitted changes before that.

What we do instead is: shelve the changes currently in our working tree,
update the checkout, and then unshelve.

This will result in a merge of the local changes against the *current*
branch tip, and places the work where it belongs: with the changes that
are not yet committed in the branch.

There's no commit of any of those changes until you decide to commit.

>     This means you have a commit that is a combination of a merge and
>     a change and it's very difficult to track what just happened.

Perhaps we're confused over terminology. What is a merge, if not an
automated change to the working tree?

If it's difficult to track what happened, that seems to be because the
user is choosing the confusion (by leaving uncommitted changes in the
tree at the time of the update).

>     We could have overcome this by switching to a distributed model or
>     making more use of "ci --local", but we didn't.

If I understand correctly, the best solution would be to educate the
team about ‘shelve’.

> 6.  Merges are completely automatic.  I guess this is related to the
>     above, but our experiences with merges trashing the working copy has
>     made us very nervous of a merge that isn't very heavily reviewed.

Merges – the change to the working tree by reconciling revisions – are
automatic, but not committed automatically.

I think I need to know what you mean by “merge” (as explored above, your
usage doesn't match what I think Bazaar means by that term) in order to
know what the problem is.

 \      “The trouble with the rat race is that even if you win, you're |
  `\                       still a rat.” —Jane Wagner, via Lily Tomlin |
_o__)                                                                  |
Ben Finney

More information about the bazaar mailing list