Comment 1 by Unknown User, May 12, 2010
added attachment bugfix_29835.patch
- bugfix_29835.patch - 2.26 kB - view
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...
Sign in to reply to this comment.
Reported by Stephen Leake, May 9, 2010