[RFC] checkout and bind should not lock the master branch

[Martin Pool]

On  2 Apr 2006, Robert Collins <robertc at robertcollins.net> wrote:
> When making a checkout, using either 'bzr checkout master' or 'bzr bind
> master', bzr currently takes a lock out on master.
> 
> This is done so that when you are binding to a master branch, and you
> have local commits, they get pushed into the master.
> 
> I.e. if you have a revision history of:
> ['A', 'B']
> in the master and:
> ['A', 'B', 'C']
> in the local branch, after 'bzr bind master', you will have
> ['A', 'B', 'C']
> in the master.
> 
> In the current ui this equates to 'turn local commits into commits on
> master when binding'.
> 
> When I merged bound branches the exact ui we would need was still
> unclear - and its now becoming fairly clear to me that we want a
> low-automation ui for this: bind, unbind should not be muddling with
> what commits are where - we have commands for that, and the ui
> understands that when bound you can have local commits.

An earlier model said that when bound, you by definition couldn't have
outstanding local commits -- in that approach, making bind push or merge
seemed to make sense.   Now we have changed that there is less of a
reason for bind to do anything but establish the binding.

> So the proposal is to remove this 'syncronisation' step during 'bind' -
> if you bind in the example given above, you'll end up with 'C' as a
> local commit - ready for you to either revert or to push into the
> master.

And will that literally be a 'push' command?

I suppose we could give a message at bind time saying whether there are
any local commits, or any unpulled remote commits, or both.  (A custom
version of 'missing').

> This will mean that 'bzr checkout' does not need to take out a write
> lock on the master, and you will be able to checkout readonly branches.

That sounds like a useful thing.

-- 
Martin