Experiences with Bazaar in a Commercial Environment

[A. S. Budden]

On 21 February 2012 01:45, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
> "A. S. Budden" <abudden at gmail.com> writes:
>
>> On 20 February 2012 20:57, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
>> > "A. S. Budden" <abudden at gmail.com> writes:
>> >> 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.
>
> […]
>> 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.
>
> Right. That is explicitly keeping your local repository distinct from
> the remote one, and getting new revisions as a merge from a different
> repository.
>
>> 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).
>
> What behaviour would you expect here? The problem seems to be that of
> setting up multiple parties to commit distinct changes to the same
> repository.

I'm not really sure.  I guess I would have liked a little more
guidance in the documentation about issues that are likely to be
encountered; maybe with a discussion about how (I assume) "ci --local"
can be used to combine the benefits of centralised with some of the
benefits of distributed.  I understand the refusing to commit, I just
don't want to update until I have done so.

> It seems you're willing to change the workflow to avoid this problem;
> why, then, name this as a problem with Bazaar?
>
> Or, in other words: If you're deliberately allowing multiple people to
> write to the same repository, I don't see how “merges get intertwined
> with commits” is an issue to lay at Bazaar's feet.

I guess I worded my discussion poorly: I didn't intend to blame Bazaar
for this (I think I said that this was probably our fault for choosing
a centralised model).  I fully understand that this problem was with
the workflow and not implicit to Bazaar.  This was one of the reasons
that we decided to look at alternatives to the way we were using
Bazaar.  As it was causing us issues, it quickly became clear that the
developers were going to have to change the way they work considerably
(either by using Bazaar-as-a-DVCS or using Mercurial).  It was felt
that the difference between relearning a way of using Bazaar and
learning Mercurial was relatively small and the more significant
issues that we were having with Bazaar (GUI ones mainly) were such
that Mercurial was chosen rather than relearning Bazaar.

Interestingly, the centralised model support was very very popular
with the team (compared with fully distributed) as (I think) it was
easier to grasp when you're used to PVCS et al.  It was one of the
main helpers in allowing me to get our team weaned off PVCS!

>> 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.
>
> Right. Choosing a heavyweight checkout means you've chosen a model that
> pretends all these changes are part of the same line of development; if
> that's violated, then the conflicts are merged as best Bazaar can do,
> and the conflicts are in your lap.

Yes.

> As you've discovered, you can deal with this by using separate branches
> explicitly and merging changes in as a separate operation. That's true
> with Bazaar as it is with Mercurial.

Indeed.  We have tried to do this as much as possible.

>> 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
>
> Thanks for explaining. It seems the options for centralised workflow
> might not have been adequately communicated to you back then.
>
> Does the current cantralised workflow tutorial fare any better?
> <URL:http://doc.bazaar.canonical.com/bzr.2.4/en/tutorials/centralized_workflow.html>

It's quite good.  I think it would be really useful to have discussion
of what happens (and more importantly how you can cope with it) when
two developers are working on the same branch.  While they can work on
independent branches most of the time, there will be times when they
don't (whether or not they should).  I could be wrong about this as I
haven't played with it, but in my idle ponderings, I've assumed that
if I did "ci --local" before update, it might work okay: create an
implicit, temporary branch which is then merged almost immediately.
Is this true?  If so, this could make for a fantastic way of working
for those companies that don't want to go fully distributed: use
heavyweight checkouts but keep the work commits isolated from the
merge commits.  I don't think I've ever seen this in the documentation
though and as I said, I never really played with it.

>> >>     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...
>
> Where would you expect it to be explained in the documentation? (I ask
> because I value the unfamiliarity you possess and I don't.)

I'm not sure of the ideal spot, although if this is the way to isolate
work commits and merge commits, I'd expect it to be listed fairly
prominently on the centralised workflow tutorial.  I'd also expect it
to be mentioned in Bazaar Explorer when it tells you that your working
copy is out of date.  I must confess I'm still wary of this one.  I
haven't played with the 'shelf' much, but my (limited) understanding
suggests it essentially converts the working changes into a patch
which is filed away.  You then update your working copy and re-apply
the patch.  If it applies cleanly, you've won.  If not, you've got the
same work commit/merge commit intertwining issues that I discussed
before.  Am I wrong in my understanding of this?