Re: New branch name with no other changes

We use the `mtn cert branch... mtn update to new branch' approach on our 
project at work. All changes are done on their own branch and we felt 
that setting up the new branch beforehand would be far less likely to 
cause problems (only approved work would be started). We felt that 
hoping a dev would remember to use the -b switch on their first mtn ci 
was more error prone (especially when they weren't used to the tool at 
that point).

With mtn you get to choose :-)

And yes you get the revision where the fork took place being on two 
branches, but as you would expect, this caused no issues.

Tony.
Richard Levitte wrote:
> In message <[email protected]> on Fri, 10 Jun 2011 16:40:59 +0200, Thomas Keller <[email protected]> said:
>
> me> Am 10.06.2011 16:26, schrieb Hendrik Boom:
> me> > Actually, the approve command worked fine, though it took a few moments 
> me> > to determine the right revision ID.  Maybe approving the revision in the 
> me> > current workspace should be an option on that command?  I wouldn't want 
> me> > it to be the default: too easy to approve the wrong thing by accident.
> me> 
> me> You could use
> me> 
> me> 	mtn approve -b new.branch w:
> me> 
> me> for the very same purpose and don't have to figure out the current rev
> me> id at all.
>
> But that places the current revision in the new branch as well.  Was
> that Hendrik's intention, or was the intention that the next revision
> should end up in the new branch?
>
> What you'r forgetting, by the way, is that approve will not place the
> workspace in the new branch, so the next commit after that will end up
> in the original branch.  I don't think that was Hendrik's intention.
> So for completeness, you really need the following:
>
>  	mtn approve -b new.branch w:
> 	mtn update -r h:new.branch
>
> However, as far as I understand, Hendrik really just wants the next
> commit to end up in the new branch.  The simplest way to do that is to
> edit the branch setting in _MTN/options...  I really think we should
> have a 'mtn branch' that does exactly that.  Last time I suggested
> that, there were a number of comments arguing the idea on grounds I'm
> not sure I've understood...
>
> Cheers,
> Richard
>
>