Re: New branch name with no other changes

On Sun, Jun 12, 2011 at 04:24:35AM -0400, Stephen Leake wrote:
> Richard Levitte <[email protected]> writes:
> 
> > 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?
> 
> He said "it worked fine" :)
> 
> > 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.  
> 
> That is my process; I always create a new branch by adding a cert to an
> existing revision, then checkout the branch into a new workspace, while
> the current workspace remains on the original branch.

That's exactly what I ended up doing.

> 
> I maintain a strict correlation between workspace directory name and
> branch name; I _never_ change the branch in an existing workspace (I
> just find that confusing, and I often want to diff between branches to
> see what has changed).

And that strict correlation sounds like a good policy!

So my real problem was not knowing about the approve command.  I may 
have heard about it before, but if I did assumed it was for reporting on 
the success of testing, rather than providing a branch name.

-- hendrik