[MERGE] fix bug #39542 for heavyweight checkouts

Robert Collins robertc at robertcollins.net
Tue Sep 12 00:28:39 BST 2006


On Mon, 2006-09-11 at 11:18 -0500, John Arbash Meinel wrote:
> 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 0.10.0RC1  2006-08-28
> 
> Isn't this an API change, which means we are supposed to go through the
> deprecation dance?

Not all apis are equal. We need to consider how badly things fail when
we change, and whether its worth supporting. Ideally yes, we'll always
be compatible. In this case the return type isn't changing, the
conditions for when bind raises explicit errors are not changing - but
the behaviour of pushing and pull is changing.


> >          :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.

Well, connect/disconnect are IMO more confusing than bind/unbind inside
the API. A 'connected branch' would to me imply something to do with
Transport. 

> 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

Exactly why I'm thinking that not raising Diverged would be a good idea.

> 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'.

Thats correct. Right now the 'bind' command is confusing users of
heavyweight checkouts on IRC. We've got this magic command that users
are being taught about from wiki pages etc *instead* of using commit
--local.

> 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'.

I'm happy to deprecate bind the api for a different one, but I think
connect/disconnect would be something that we'd look back at in 2 months
and say 'what were we thinking'.

If we want a good name, why not one that is descriptive : (strawmen)
be_checkout_of(other), and be_standalone()

> 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.

I'll merge the prerequisites now while we discuss this further.

Commit might be a reasonable place to push up the revisions. It occurs
to me though, what should someone do when they have local commits, but
no additional local changes. Is 'commit' still the right place? If so,
perhaps status really should show that they are out of date, with status
--local doing local status.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060912/bb2e02d6/attachment.pgp 


More information about the bazaar mailing list