Issue 77: 'update -b' fails where 'update -r h:b' succeeds

Reported by Stephen Leake, May 9, 2010

(This entry was imported from the savannah tracker, original 

Stephe Leake@sabul$ mtn heads
mtn: branch 'net.venge.monotone.bugfest-2010.9269-stephen_leake' is 
currently merged:
d8a2add47319b83ac7657d34df8f69c028b61208 5/8/2010 4:24:24 PM

Stephe Leake@sabul$ mtn update -b net.venge.monotone
mtn: updating along branch 'net.venge.monotone'
mtn: misuse: your request matches no descendents of the current 
mtn: misuse: in fact, it doesn't even match the current revision
mtn: misuse: maybe you want something like 

Stephe Leake@sabul$ mtn update -r h:net.venge.monotone
mtn: expanding selection 'h:net.venge.monotone'
mtn: expanded to '8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea'
mtn: selected update target 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea
mtn: target revision is not in current branch
mtn: switching to branch net.venge.monotone
mtn: [left]  6392793f219bc51281ad4fa5f52a5f5cfb68b556
mtn: [right] 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea
mtn: dropping tests/log_with_windows_dirsep/__driver__.lua
mtn: dropping tests/log_with_windows_dirsep
mtn: updating NEWS
mtn: updating monotone.texi
mtn: updating win32/
mtn: switched branch; next commit will use branch net.venge.monotone
mtn: updated to base revision 

why should 'update -b foo' fail when 'update -r h:foo' succeeds? 
They are supposed to mean the same thing.

(This is similar to 13597, but not the same)

Comment 1 by Unknown User, May 12, 2010

added attachment bugfix_29835.patch

Comment 2 by Unknown User, May 12, 2010

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

Comment 3 by Thomas Keller, Jun 22, 2010

There is a third mode:

3. with branch and revision: updates to the specified revision if 
one of its branch certs matches the given branch name (note also 
#29843), otherwise aborts

I agree that the behaviour of -b branch vs -r h:branch is somewhat 
odd, and especially at the beginning I found that somewhat confusing 
as well. But if we make --branch foo mean h:foo, we're effectively 
overloading the meaning of this option in other places and this 
could create a bigger mess IMHO.

I'd go one step back and would ask if we really need the ability of 
switching the workspace revision only with a branch argument... is 
that actually used by anybody? I certainly always trigger -rh: and 
only give it another -b option if the target revision's branch 
doesn't match my current branch and contains ambigious branch 

Created: 13 years 6 months ago by Stephen Leake

Updated: 13 years 5 months ago

Status: New


Quick Links:    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status