From: Larry M. <lm...@bi...> - 2011-03-10 15:39:47
|
On Thu, Mar 10, 2011 at 10:34:11AM -0500, Donald G Porter wrote: > Jeff Hobbs wrote: > > How do you modify this behavior for backporting? A common and necessary > > step as many people only focus on the head, leaving others to move back > > fixes to stable or older branches. > > I haven't been using the system long enough to have developed a Grand > Unified Theory of fossil merging yet. I raise the point of merges from > 8.4 forward because that scenario just happened, and I happened to be > the one bit by the result. Rather than e-mail one offender, it seemed > good to share the advice with all. > > My aim is that we find a set of practices such that a default > > fossil merge core-8-5-branch > > on the trunk just does the right thing, without much need to fuss with > --cherrypick and --baseline options. Unless you have a real SCM file format, --cherrypick is just a fancy term for diff&patch, right? So the content then gets in the other branch as a copy, not the original source. That can lead to problems. I'd suggest that you consider two branches for each legacy branch: core-8-5-branch # everything here can be pulled forward core-8-5-branch-backports # core-8-5-branch merges TO this only It's very pleasant if you make all your legacy stuff be subsets of your new stuff. $DVCS will do a pretty decent job of merging that, or it's a really sucky $DVCS. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com |