On Mon, Feb 27, 2012 at 5:15 AM, Julian Foad <julianf...@btopenworld.com> wrote: > As many of you are aware I've been looking at improving merge in various > ways. I'd like to ask for feedback at this stage on the Wiki page > <http://wiki.apache.org/subversion/SymmetricMerge> (renamed from > SvnMergeTheory). The essential point is that it looks like we can relatively > easily enhance Subversion so that a plain 'merge' command will act as either > 'sync' or 'reintegrate' automatically, depending on the history of the > branch, and furthermore will work better than either of them in the scenario > of continuing work on a branch after a reintegrate. > > How much of what I've written makes sense? I know it could do with much more > detailed worked examples, with concrete Subversion commands and output to > prove the connection between theory and practice.
I think I followed most of it - nice work. I did get a bit lost about how we'd continue to handle cherry-picking. At $dayjob, we follow much the same pattern that we do here in Subversion - having a "stable" branch that gets cherry-picked revisions from the mainline trunk. But, those stable branches are usually one-way dead-ends - so, reintegration isn't often necessary. Perhaps that'd be a better way to differentiate it - that *most* branches that use cherry-picking aren't often going to be targets for reintegration. Here in SVN itself, I don't imagine that we'd ever really want to reintegrate trunk with changes we made (only) in a stable branch... For branches that tend to be reintegrate targets - feature work on a short or long-lived branch - I tend to see it's a different pattern and doesn't usually involve cherry-picks - it's more the sync/reintegrate model with complete merges you've discussed throughout the rest of the document. Anyway, maybe that's a more helpful way to separate the use cases. I look forward to it in 1.8! -- justin
