Reported by Stephen Leake, May 9, 2010
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?29835) Stephe Leake@sabul$ mtn heads mtn: branch 'net.venge.monotone.bugfest-2010.9269-stephen_leake' is currently merged: d8a2add47319b83ac7657d34df8f69c028b61208 email@example.com 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 revision mtn: misuse: in fact, it doesn't even match the current revision mtn: misuse: maybe you want something like --revision=h:net.venge.monotone 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/main.cc mtn: switched branch; next commit will use branch net.venge.monotone mtn: updated to base revision 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea 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 certs...