On Mon, Feb 27, 2012 at 5:15 AM, Julian Foad <julianfoad_at_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
Received on 2012-03-02 09:46:32 CET