[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: [bug #29835] 'update -b' fails where 'update -r
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Re: [bug #29835] 'update -b' fails where 'update -r h:b' succeeds |
Date: |
Thu, 13 May 2010 07:26:07 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt) |
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