Experiences with Bazaar in a Commercial Environment
Stephen J. Turnbull
stephen at xemacs.org
Wed Feb 22 09:13:15 UTC 2012
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.
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
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
> 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.
More information about the bazaar