Re: Locks on the Bzr repository

["Stephen J. Turnbull" <stephen@xemacs.org>]

Jan Djärv writes:
 > 
 > 
 > Stephen J. Turnbull skrev 2010-08-21 20.59:
 > > The workflow should be something like
 > >
 > > 0.  work in "work", a branch of "mirror" (local) which is in turn
 > >     a branch of "trunk" (on Savannah)
 > > 1.  pull from "trunk" into "mirror"
 > > 2.  rebase "work" on "mirror"
 > > 3.  repeat 0-2 until done
 > > 4.  cd to mirror& pull from "work" into "mirror" (this will
 > >     always succeed!)
 > > 5.  push from "mirror" to "trunk"
 > > 6.  if 5 succeeds, you're done (for now, go to 0 to start the
 > >     next change)
 > > 7.  else pull --overwrite from "trunk" into "mirror"
 > > 8.  goto 2
 > 
 > I do something similar, but 5 is a commit on a bound branch.  Is
 > there any difference between that and push?

Speaking very precisely, I think you must be doing something different
from what I think you mean.  If "mirror" is a bound branch, then the
pull in step 4 will operate on "trunk" (ie, the Savannah mainline)
before operating on "mirror".  If the pull succeeds, you're done;
Savannah, "mirror", and "work" are all identical (except for
unversioned "junk").  There should be no need for a commit at that
point.

Since I am not sure exactly what you're doing, you shouldn't rely on
the rest of what I say for yourself.  It works for me, but since I'm
guessing about your workflow, I can't be entirely sure if it should
work for you.

In principle, no, there would be no difference in the case of a
success.  It's the failure modes for commit-while-bound and commit-
then-push that are different.

Specifically, in a bound branch, the pull in step 4 from "work" into
"mirror" can fail if someone has committed *on Savannah* while you
were rebasing.  Or, if you merge, or work in the bound branch, instead
of pull, the commit can fail.  This means that bzr has no record of
the work you are trying to push.  If you don't make any changes while
the commit is in process, then the workspace is your record, and you
can just fix the problem (typically, bzr update "mirror", build and
test, and retry the commit).  If you have made changes, however,
you've got to untangle your mess by hand before updating "mirror".

In the commit-then-push workflow, you have the commit, and you can
then continue to work in that workspace while you're waiting for push
to complete (successfully or not), knowing that Bazaar has a record of
all your work up to the push.  (Typically I will commit several times,
test, and then push.)