Re: Locks on the Bzr repository

[Uday S Reddy <u.s.reddy@cs.bham.ac.uk>]

Perhaps I can sneak in a few comments while Stephen is offline.  I have found 
this debate quite enlightening and it helped me understand the limits of 
"distributed" VCS.  (I use unbound local branches in working on VM and always 
wondered why you guys use bound branches.  I am beginning to understand a 
little bit now.)

On 8/20/2010 4:19 PM, Eli Zaretskii wrote:

>>
>> Sure.  So don't do that.  One (probably for values of "one" != "eliz")
>> can pull instead, and rebase when necessary to get that to succeed.
>
> Please show this workflow in more detail.  Without the details, it's
> hard to tell what you suggest.  You could be thinking about things
> possible with git, but not with bzr; it happened in the past.

I think one needs to do a pull before each commit, to be safe.  (Seems to be 
the same as update-commit cycle for bound branches.)

If you have already done a series of commits and lost the opportunity to pull, 
then you have to rebase.

If even that seems too far out, then you have to make your changes into a 
separate branch and merge it in later.

> I don't use lightweight checkouts.  I use one bound branch and 2 or 3
> local branches.  I have no problems with local commits, which I use a
> lot.  The problem happens when I need to commit to the master
> repository.  I need to do that from time to time, because my local
> commits are not available to others, so if I fix bugs, my fixes will
> not be good to anyone until I commit to upstream.

It seems to me that committing to the bound branch is essentially like push. 
(Somebody said you were "discouraging" push.  I don't see it.  Your every 
commit is a push.)

However, we get to use our local mirror of the trunk as if it were a local 
branch.  We can commit to it without affecting anybody else and do a public 
commit only in the end.  We can commit to it as often as we please, keep a 
careful log, do enough testing etc. And, this local branch can magically turn 
back into a proper mirror as soon as we do a rebase-push.  You can't get this 
with bound branches.  Your local branches have to be necessarily separate 
branches, whose histories will appear as merges in the mainline.

We use separate local branches as well, when they are appropriate.  But we are 
not forced to use them all the time.  (Generally, I am happy to use the main 
branch for a few days worth of work where I can see the end clearly.  I use 
separate branches for things that might take a few weeks, or things of a more 
open-ended nature.)

   And doing so is
> painfully slow, and there seems to be no way around it.  On top of
> that, sometimes a commit fails, because someone holds a lock or
> because some other commit was "sneaked" in in the meantime.  So I need
> to watch the commit and make sure it succeeds, or start another one if
> it doesn't.  So please don't tell me this is asynchronous, because it
> isn't, at least not entirely.

Seems to me that you are reinforcing Stephen's point.  With bound branches, 
your branch is locked up until the commit goes through.  You can't do anything 
while you have uncommitted changes in your source.  With unbound branches, we 
can continue working on the source even when push is running in the background, 
because the source tree doesn't have any uncommitted changes.  We can also give 
up on the push if necessary and continue committing to the branch.  The 
advantage seems quite clear to me.

> No big deal.  But the disadvantages of each workflow need to be well
> understood before making a decision which one to use.

I can't believe that you guys really understood the disadvantages of your 
current workflow before settling on it.

The most illuminating revelation I found in Stephen's post is that, with bound 
branches, every commit is a merge.  Most of the time, it is untested and 
unsafe.  This is the biggest disadvantage of all, if you ask me.

It also occurs to me that, by asking everybody to use bound branches, you have 
massively increased the contention on your public repo and the server.  That is 
making your problems worse.

Cheers,
Uday