Re: Locks on the Bzr repository

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Aug 2010 12:30:44 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org
> 
> > Actually, I see no reason not to continue working even in the bound
> > branch that is being committed.  There's nothing at all to prevent
> > that, since Bazaar takes note of the files it commits and their
> > contents _before_ it sends changes upstream.  That is why you cannot
> > make changes after launching "bzr ci" and hope for them to be included
> > in the changeset.  (This is unlike CVS, where you could make changes
> > as long as the particular file wasn't sent upstream by "cvs ci".)
> 
> This is correct.  However any bzr operation like a simple C-x v = fails 
> because bzr is locked by the commit (it doesn't seem to do read-only locks). 
> That is the main disadvantage that makes me go back to the task branch.

I agree that this is a disadvantage, but is it really that
significant?  How much do you use bzr operations while developing?
Most of development is not about bzr, it's about editing, compiling,
and testing.  I only need bzr operations when I'm almost done with
development, like to see what files are changed or compare them with
some other version.  No matter how slow is "bzr ci" upstream, the
development cycle is much slower, at least for me.  It can only be
faster if you fix very simple bugs, like typos.

YMMV, but this disadvantage doesn't sound a reason good enough to make
a cardinal decision to do all the work from a task branch.