Experiences with Bazaar in a Commercial Environment

[A. S. Budden]

On 20 February 2012 20:57, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
> "A. S. Budden" <abudden at gmail.com> writes:
>
>> Apologies for the long email...
>
> Thanks for taking the time to make your thoughts comprehensible.

Pleasure: shame they weren't all 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
> problems.
>
> 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.

Okay, this wouldn't be the first time I've been accused of ambiguity;
perhaps I can explain better.  If I may, I'm going to compare this
with my (albeit limited) experiences with 'the other VCS'.  I should
make it clear at this point that I said in the original post that this
is "probably our fault for using checkouts rather than a proper
distributed model" and I suspect my comments about Mercurial apply to
distributed-mode-Bazaar as well.  That isn't how we used it and we had
problems.  Whether that was our fault or not, I was trying to make a
statement of why we are changing.  Anyway, this is what I was trying
to say:

In Mercurial (and probably also in Bazaar-as-a-DVCS), I make some
changes to my local working copy.  I commit those changes.  I get
changeset 17 (say) which is a representation of what I was intending
to commit.  I then pull from the server, which creates multiple
'heads' (as Mercurial calls them).  I merge, which combines my
changeset 17 with the remote changeset (say '18' for the sake of
argument) and I commit a new changeset 19 with the result of the
merge.  Changeset 17 is what I wanted to do, changeset 19 is a merge.

In Bazaar in the way we used it, I make some changes to my local
working copy.  I hit commit, but it refuses to commit because the
working copy is out of date with the network copy (remember this is a
heavyweight checkout).  It tells me to update to the latest version on
the network.  I do so and it auto-merges my working copy with the
network version.  I commit the merged work as changeset 12 (say) and I
get a single changeset that combines my work and the effect of the
merge.  If some mistake was made in the merge (either by the tool or
by me), I now have a commit that doesn't work and the reason is quite
difficult to work out.

Does that make any more sense?  I realise there are ways we could have
worked round this, but we followed what seem to be the expected way of
centralised working at least at the time we started (I got the
impression that heavyweight checkouts were no longer as
enthusiastically support as lightweight ones as time went on, but that
could be me reading too much into things).  We had problems and it was
one of (but not a major one of) the reasons we decided to move away.
Compared to the Bazaar Explorer crashes, it was VERY minor.  Compared
to my slightly facetious comment about naming puns, it was probably
quite major!

>>     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).

I can see that shelve might be a good option here.  At the time I
wrote our internal "How to Install & Use Bazaar" document, which runs
through the way to do things, shelve wasn't supported by Bazaar
Explorer at all as far as I could see (remember I'm the only command
line fan).  I haven't checked whether or not this is still the case.
As I remember it (and my memory is very very fallible), when we
started using Bazaar, shelve was part of the BzrTools plugin and we
were trying to avoid plugins unless absolutely essential.  Certainly
even with the latest version we have, if you try to commit and someone
beats you to it, Bazaar Explorer/QBzr suggests that you either update
or do a local commit.  The first I've heard of the suggestion of
shelving your changes is your email.  It also concerns me a bit
(although it's a bit academic now): if I shelve changes, update to the
latest network version and the shelved changes do not apply cleanly to
the newest version, what happens?  Do I still have a clean commit of
the work that I've done, or do I have to re-do it and potentially
break my code before I've had a chance to check it in?

>>     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’.

Maybe, although I'm still not convinced this is very well explained in
the documentation...

>
>> 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.

And that's a VERY good thing!  Mercurial (or at least TortoiseHG) does
this too, but it allows me to ask it to do the automatic merge on a
per-file basis, rather than doing all the files automatically straight
away.

> 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.

Hopefully I've explained the problem a bit better now.  Let me know if
you need more information.  As I said, this isn't even approaching the
number 1 reason for the move.  If I wanted to put them in order of
priority I'd probably say:

1. Bazaar Explorer crashing regularly
2. Lack of tool support
3. Externals issues (not properly locked revisions and lack of GUI support)
4. Binary conflicts are messy
5. .moved directories wherever directories are present in one branch
and not another and you 'switch'
6. GUI diffs with multiple files having changed
7. Everything else.

but that's just off the top of my head and others would probably
disagree.  One of my colleagues stated his reasoning for not liking
Bazaar as being that he "doesn't trust it", but he couldn't give me a
tangible reason for that...

Al