Recommended use of Bazaar for single-committer multiple-machine projects?

Martin Pool mbp at
Fri Dec 12 22:42:43 GMT 2008

On 12 Dec 2008, "Matthew D. Fuller" <fullermd at> wrote:
> On Fri, Dec 12, 2008 at 06:31:27PM +1100 I heard the voice of
> Mary Gardiner, and lo! it spake thus:
> > 
> > OK. so essentially you don't in this model do a lot (or any) --local
> > commits. It may be that this is an improvement in terms of avoiding
> > the various two-merges problems that working directly in the
> > checkout cause.  I'll give it a go. (Still interested in other
> > workflows though.)
> That's the sort of thing I'd aim at too.
> I consider --local to be far more of an escape hatch, and far less a
> daily tool.  It's an inherently schizophrenic thing to do; branches
> can be shared (as in a checkout) or independent; --local users the
> former to emulate the latter.  Certainly it has unnecessary bugs like
> you've mentioned, but even with them fixed, it's [IMAO] much better
> considered a special-case stopgap, than a regular-use device.

I was just wondering (in the light of Mary's bug reports) whether we
should in fact remove the --local commit feature.  It was a good
experiment, and I think checkouts are really useful, but local commits
not so much.

It feels like they really want to be adding a new default or mode of
use, and at one level they do, but actually they work quite differently.
They create some additional complexity in code, in bugs, in
documentation and in the kind of situation users can get into and how
they understand them.

Getting rid of them would mean we could still have checkouts, but
committing to a checkout would always go into its branch, whether that's
on the same machine or elsewhere.  So this would mean checkouts of a
remote branch would only really work if you had access to the server,
much like in svn, though you would be able to do wt-only operations with
no connection.

We wouldn't need the four-way merge of wt-basis, wt, local branch,
remote branch, that can currently happen in updates.

Martin      <>

More information about the bazaar mailing list