Experiences with Bazaar in a Commercial Environment

[Ben Finney]

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

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.

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

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.

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

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

Thanks again for your time putting this feedback into a useful form.

-- 
 \            “There was a point to this story, but it has temporarily |
  `\                    escaped the chronicler's mind.” —Douglas Adams |
_o__)                                                                  |
Ben Finney