[RFC] bound branches initial ui

[John Arbash Meinel]

Robert Collins wrote:
> 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!

Now we can rename the command 'bzr enslave' though really that is
working the wrong way. Maybe 'bzr sell-into-slavery' :)

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

Well, if 'bzr commit' does the pivot, then it seems okay to have 'bzr
update' prepare the branch such that a commit will make it pivot.
As long as you haven't actually changed my 'revision-history' yet, so I
can 'bzr revert' and get back to a branch with only my changes.

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

Update + revert with a checkout means I lose my changes. update+revert
with a diverged bound branch should lose the master changes. I do see
them being different.

With a non-diverged bound branch, then we definitely should strive to
have near identical actions as a checkout. It is just a heavy checkout
which lets me diverge/go offline if I ask it to. Without having to plan
ahead. (I can convert a checkout to an offline branch if I think about
it before I pack my bags, but not once I'm on the plane).

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/20060221/a138c4f8/attachment.pgp