Experiences with Bazaar in a Commercial Environment

[Stephen J. Turnbull]

A. S. Budden writes:

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

In a DVCS, you don't expect this behavior because you're committing
locally.  In a CVCS, you expect this do expect this behavior.  Bazaar
bills itself as a DVCS, so users get confused.

 > > The problem seems to be that of setting up multiple parties to
 > > commit distinct changes to the same repository.

This is a bit inaccurate.  The problem is setting up multiple parties
to commit to the same *branch*.  git (for example) will hide the issue
behind tracking branches, so that each user will have a local branch
with the same name, but workspaces are never merged with commits;
multiple commits are merged and a new commit appended.

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

You need to use branches.  Of the existing DVCSes, I suspect that you
will be more comfortable with Mercurial, which will force you to put
each user's commits on a separate branch, and defer conflicts to the
point of a push.  But see below about an "implicit --local" that might
make Bazaar capable of DWIMming for you.

 > > It seems you're willing to change the workflow to avoid this problem;
 > > why, then, name this as a problem with Bazaar?

He's been pretty careful in general not to call anything a problem
with Bazaar; these are problems his organization has encountered in
using Bazaar.  If a particular workflow leads to confusion among
users, he is simply suggesting that it be documented.

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

No, it *is* specific to Bazaar.  Bazaar is the only major DVCS that
encourages you to merge into a dirty workspace.  In hg and git, you
have to either commit or do something special in order to merge in a
workspace with uncommitted work.  All three have "shelve" features,
but the other two force you to learn about them.  For users migrating
from a CVCS, the ability of Bazaar to update a workspace without a
commit is an attractive nuisance.  (I don't like it period, but YMMV.)

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

I don't think so, but I don't have an implementation.  I think Bazaar
can do better, specifically it could handle this with "implicit
--local commits".  Bazaar would automatically commit the workspace,
then merge that "implicit commit" with the incoming update commit(s).
This is a bit delicate (compared to git or hg) because Bazaar has a
notion of "mainline", but I suspect that (for the use case in
question) this can be satisfactorily resolved.

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

This can be prevented (see "implicit --local" above).

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

Yes, but I think in practice we can probably do better, as I suspect
most people will want a merge of local commit into incoming mainline
commit most of the time.  It needs to be implemented though.

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

Not necessarily.  "shelve" in principle does something different from
"ci --local".  Specifically, it (in some sense) cuts off the
uncommitted work from the (local) repo, where "ci --local" appends it
immediately.  This implies decisions about when to recommit the
shelved work.

In principle, that's good.  However, I suspect that from the point of
most users in the heavyweight checkout workflow, they perceive their
(uncommitted) work as a ready-to-commit continuation of the parent
commit in their workspace.  So an immediate "ci --local" matches their
expectation better.

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

I thought the real problem is that the uncommitted work is
uncommitted, and thus gets confounded with conflict resolution.  The
difference between this workflow and the "ci --local" workflow is that
in the shelve workflow the resulting history will be "local tip" ->
"merge of outside work" -> "new local work", while the "ci --local"
(explicit or implicit) workflow gives the history "local tip" -> "new
local work" -> "merge of outside work".  I think the latter is
probably going to be more intuitive to your colleagues.