[RFC] bound branches initial ui

[Robert Collins]

On Tue, 2006-02-21 at 21:26 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:
> > Hi, we've just talked through bound branches - whether to have unbind
> > --temp or a flag to commit to control when to pivot.
> > 
> > What we agree makes sense as first cut ui for 0.8 is:
> >  * use 'update' to update the bound branch against the boundee rather
> > than pull, because pull should pull from the parent branch. If there is
> > no working tree, update can still try to update the branch, but if there
> > is divergence give an error instructing the user to make a checkout and
> > then run update in it.
> 
> This I definitely agree with. +1
> 
> In my bound-branch code, I found it easier to reference the 'boundee' as
> the 'master' branch. I don't care a lot about terminology here, but I
> would like to be consistent, and I find 'boundee' clumsy. It definitely
> doesn't flow for me. Everytime I see it I have to think too much.

Great, master it is. Slave branches ahoy!

> > If there is local divergence during an update,
> > the boundee's tip becomes a pending merge.
> 
> This I'm not so sure. Why not just say "these branches have diverged,
> use 'bzr merge'".
> 
> I'm not sure that 'bzr update' should throw away my revision-history
> without giving me a chance to change my mind. +1 if 'bzr revert' reverts
> me back to my diverged branch. But the default with the current code
> would throw away my changes.

In the proposal I sent in it does not throw away your revision history.
'update' != 'pull --overwrite'.

> My idea is that I got on a plane and I made a couple of commits. Then I
> came back online, and I habitually run 'bzr update'. I see that the
> bound location has diverged in such a way, that I want to put my stuff
> in a new feature branch.

You should have the option to do the following:
$ bzr commit
ERROR: Out of date branch: Your branch is out of date with the master
branch, you need to update before you can perform a commit. If you have
uncommitted changes consider running 'bzr commit --local' before
updating.
$ bzr commit --local -m 'Preparing to update'
Committed local revision 4
$ bzr update
> Assuming no conflicts:
You have local commits. Please run 'bzr commit' to send your local
commits to the master, or 'bzr commit --local' to record that you are
now up to date with the master.
> With conflicts:
Conflicts detected:
...
You have local commits. Please resolve the conflicts and then run 'bzr
commit' to send your local commits to the master, or 'bzr commit
--local' to record that you are now up to date with the master.
$ bzr revert
$ bzr st


> I realize that the common case is as you described. I made my changes,
> now when I 'update' I'm really saying to merge my changes and get back
> in sync. My concern is that after running 'update' it is very difficult
> to get back to my other changes in case I want to actually diverge at
> this point.

Yes. I think that pivoting during update would be 'neat' but its too
hard for a first cut at the ui.

> >  * have commit by default operate in lockstep with the boundee branch.
> 
> +1.
> 
> > If there is divergence it should instruct the user to either 'update' or
> > 'commit --local' and then 'update'.
> 
> Same issue as above. I suppose doing 'commit --local + update' at least
> means your changes would be preserved as a specific delta. While doing
> 'update and then commit' means you have to resolve the conflicts before
> you can commit your changes. So the conflict resolution hides your
> original change.

yes, although we could get most of it back.

> >  * have 'commit' when there is local divergence *and* the branch is
> > either fully up to date with the boundee or has a pending merge of the
> > boundee's tip perform a logical pivot and commit against the boundee's
> > last-revision with the current divergence as a merge.
> 
> So this is saying that 'commit' will act like push if given the right
> conditions. Before now I thought the idea was that if you were diverged
> you would 'bzr merge; bzr commit; bzr push', and then you would no
> longer be diverged. You are saying that commit will do the final push
> for you.

Yes, 'bzr commit' would only work when it can commit to the master.

> >  * have commit --local to start local divergence - to replace the CVS
> > edit & edit & copy & edit sequence with edit & edit & commit --local &
> > edit.
> 
> Does 'commit --local' break the binding? From the sound of it, it
> doesn't. Which means that you need to do it repeatedly if you want to
> stay in a quasi-bound state.

Yes. Users do this in svn and cvs all the time, when for whatever reason
they don't want to create a full branch.

> Does that mean when you are 'offline' you have to 'commit --local' the
> whole time? (Or unbind)

Yes. 

> > 
> > We felt that three-valued modal interface 'bound or bound and offline or
> > not bound' was less clear than an entirely optional switch to 'commit'
> > which people can find out about when they are ready for it.
> > 
> > Seeking +1s and -1's.
> > 
> > Rob & Martin.
> 
> I kind of like 'commit --local', since it says, "I know I'm bound, and I
> want to stay that way, but just this once, let me diverge until I can
> resolve things later".
> 
> Overall, I think I like the proposal. 'commit --local' is growing on me.
> I think you are making the commands easy to use, and fairly intuitive.
> My only concern is:
> 
>  bzr update
>  !! Oh shit I don't want this, how do I go back
>  bzr revert
>  !! Where did all my changes go
> 
> So I guess I'm +0.5

I hope my comments above clarify the 'update + revert' case - but I dont
see that its any different in the above proposal to 'update + revert'
with a 'checkout' - and thats deliberate.

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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060222/cf50056d/attachment.pgp