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

[Derek Scherger]

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.

Cheers,

Derek