Re: [Monotone-devel] Re: [bug #29835] 'update -b' fails where 'update -r h:b' succeeds

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> 2010/5/12 Stephen Leake <address@hidden>
>
>> Zbigniew Zagórski <address@hidden> writes:
>>
>> > Follow-up Comment #2, bug #29835 (project monotone):
>> >
>> > (slept with that problem and ... )
>> >
>> > 1. forget current patch, it's broken in regards to error/empty branches
>> > handling. I am preparing one new.
>> >
>> > Second, more important issue is that this changes how update works.
>> > Current update worked in two modes:
>> > 1. with -r -> updates to _anything_
>> > 2. with branch (implicit or not) -> updates only to descendants of
>> current
>> > revision
>> >
>> >
>> > This patch changed update so it would work like this:
>> > 1. with -r -> updates to _anything_
>> > 2. with branch (implicit or not) updates to
>> >   -> descendants of current revision OR
>> >   -> any head of specified branch (if merged)
>> >      (equivalent to -rh:<branch>)
>>
>>
>> > Question: do we want to unify this behaviour?
>>
>> That is the point of my bug report. What is the rationale for the
>> original behavior?
>>
>
> Possibly so that you can update to the head on the side of a fork that you
> already happen to be on regardless of whether the branch is merged or not.
> Possibly because update -r (to arbitrary revision) was developed after
> update (to descendant head) which did something like cvs update that people
> had in mind when this was originally done.
>
> When do I need 'update -b foo' to fail, but 'update -r h:foo' to succeed?
>
>
> Update -rh:foo will fail if foo is unmerged, update -b foo might succeed in
> the same case if only one head is descended from the current revision. I
> haven't tested this though so it may not be how it works. I realize this
> does not exactly answer your question above but maybe it will help arrive at
> an answer there.
>
> I can't think of a good reason that update -b foo should fail if foo is
> merged or if only one head is descended from the current revision.

So I propose the following:

a) 'update':

    if one head on the current workspace branch, update the workspace to
    it

    if multiple heads, but exactly one is a descendent of the current
    workspace rev, update to it

    if multiple heads and more than one is a dscendent, report them and
    fail.

    otherwise do nothing, and report 'up to date'

    (this is the current behavior)

b) 'update -b <branch>':

    if one head, update the workspace to it, and change _MTN/options to
    <branch>

    if multiple heads, list them and fail

c) 'update -r <rev>': update the workspace to <rev> and change
   _MTN/options to the branch cert on <rev> (the current behavior)

d) 'update -b <branch> -r <rev>' specifies the branch when <rev> has
   more than one branch cert (the current behavior), but is an error if
   <rev> has only once branch cert that does not match <branch>
   (currently not checked)


I think the current behavior is an unintendend side effect of how the
branch option is specified. In cmd_merging.cc, 'update' (with no
explicit -b or -r) uses app.opts.branch to get the "current workspace
branch"; apparently that is set earlier from _MTN/options.

Specifying an explicit -b uses the same code, with confusing results.

I hope we can use app.opts.branch_given to distinguish the two cases.

-- 
-- Stephe