Moving changes between branches.

[Matt Mackall]

On Tue, 2011-10-11 at 11:33 -0400, Tom Udale wrote:
> Greetings,
> 
> I have a question on workflow I was hoping someone could advise me on.
> 
> I finally got my cvs repo converted over to hg - thanks to everyone here 
> for help on that - and my immediate need is to do a release.  It turns 
> out that I did not predict the future very well and to do this release I 
> need to get some changes that are on the default branch (which we  use 
> as the mainline development branch) onto a named release branch, call it 
> BRANCH_X.  There are of course a ton of changes on the default branch 
> that I do not want on the BRANCH_X.
> 
> My question is, what is the best way to do this so that when I 
> subsequently merge BRANCH_X back onto the default, I don't end up with a 
> pile of problems.  Two approaches come to mind:
> 
> a) dump the changesets from default into a patch.  Revert those changes 
> from default and then apply them to BRANCH_X.  Then when I merge 
> BRANCH_X, I will get them back again.
> 
> b) dump the changesets into a patch.  Apply that patch to BRANCH_X and 
> then simply know that those files are the same on both sides when I 
> merge later and resolve it that way.

(b) is the way we do it, and merge conflicts are actually rare. See:

http://mercurial.selenic.com/wiki/StandardBranching

> It seems like transplant and mq might also be applicable to this but 
> perhaps are a bit heavy handed?

Transplant is basically shorthand for hg export + hg import, so yes, use
that.

> I have a similar issue coming up where we are going to switch compilers 
> - a big change - that I will want probably on both the dev and current 
> release branches.  Again, where to make the initial changes and how to 
> migrate them.  And how to deal with subsequent small fixes - do I have 
> to have all my devs work only from BRANCH_X to fix things that are 
> discovered to be broken on both branches so they can merge them back in 
> where they really want them??  Seems an odd and fragile workflow.

For something like this, I'd probably just do:

hg clone project project-make-new-compiler-go

Then fix things up all the compiler issues in that repo. Meanwhile,
everyone who wants to keep doing "real work" can stick to the main repo
and ignore what the compiler guys are doing. When you're satisfied that
the compiler's going to work for everyone, pull that repo into the main
repo and merge the branch heads.

You can of course do this with named branches, like
BRANCH_X_NEW_COMPILER, but if you're only going to spend a few weeks
switching over, then it's probably simpler to do it my way.

> 
> Best regards,
> 
> Tom
> 
> 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial


-- 
Mathematics is the supreme nostalgia of our time.