[MERGE] fix bug #39542 for heavyweight checkouts
John Arbash Meinel
john at arbash-meinel.com
Mon Sep 11 17:18:02 BST 2006
Robert Collins wrote:
> ``Branch.bind(other_branch)`` no longer takes a write lock on the
> other branch, and will not push or pull between the two branches.
> API users will need to perform a push or pull or update operation if
> they
> require branch synchronisation to take place. (Robert Collins)
>
> ``bzr bind`` no longer synchronises history with the master branch.
> Binding should be followed by an update or push to synchronise the
> two branches. This fixes bug #39542 for heavyweight checkouts.
> (Robert Collins)
>
> I'll merge the whole group of branches when this is approved, I think
> all the prerequisites have had +1.
>
> -Rob
>
...
> + * ``Branch.bind(other_branch)`` no longer takes a write lock on the
> + other branch, and will not push or pull between the two branches.
> + API users will need to perform a push or pull or update operation if they
> + require branch synchronisation to take place. (Robert Collins)
> +
> bzr 0.10.0RC1 2006-08-28
Isn't this an API change, which means we are supposed to go through the
deprecation dance?
...
> @needs_write_lock
> def bind(self, other):
> - """Bind the local branch the other branch.
> + """Bind this branch to the branch other.
>
> + This does not push or pull data between the branches, though it does
> + check for divergence to raise an error when the branches are not
> + either the same, or one a prefix of the other. That behaviour may not
> + be useful, so that check may be removed in future.
> +
> :param other: The branch to bind to
> :type other: Branch
> """
Someone finally mentioned a name that might be useful instead of
bind/unbind, we could use 'connect/disconnect'. Which could then be a
different api which doesn't raise DivergedBranches, and doesn't
push/pull revisions.
I can see an advantage to not raising Diverged, because then you could do:
bzr connect
bzr update
bzr commit
Rather than
bzr bind #failure
bzr merge $other/branch
bzr commit
bzr bind # success, which pushes your changes to the remote
By the way, without having 'bzr bind' push your changes, and that 'bzr
commit' now refuses to work if you are ahead of the remote branch, it
makes it pretty difficult. Because 'bzr push' does not default to the
bound location, so you have to explicitly type it again.
You keep making the 'bind' action much weaker, which I didn't really
prefer, but I'm not using it now, so I'm letting you.
Originally I wanted 'bzr bind' to get me into lock step with the remote
branch. And refuse to actually bind if it couldn't get me there.
You are changing it (especially if you get rid of diverged branches) to
be just a 'set a reference to another tree, if you want to do anything
about it, you have to use a different command'.
I'm still a little uncomfortable about 'commit --local', since you are
explicitly breaking the binding statement, without actually breaking the
binding. I understand the reasons (one is that we chose to forget the
bound location when we unbind, which makes 'bzr bind' more of a pain to
run than it should be, the other that we are trying to hide the binding
behind the veneer of checkouts).
So what do you think about side-stepping all of the bind() api changes,
deprecating bind and 'bzr bind/unbind', and going for 'bzr
connect/disconnect'.
Whatever we do, we need an easy way to push our changes to the master
branch. (Either have 'bzr push' use it as a default target, or something
like 'bzr sync', which does the steps that bind used to do).
I would like to see this get into 0.11, especially 'lock_tree_write'. So
it might be best to merge your earlier stuff while we discuss how to get
'bind' to play nice.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060911/b8ea76f7/attachment.pgp
More information about the bazaar
mailing list