On 4/17/2012 11:38 AM, Paul Burba wrote:
On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad<julian.f...@wandisco.com> wrote:
I have written out how I think a large part of the symmetric merge
algorithm should go, in more detail. Review and other feedback would
be welcome.
We need to write out the algorithm in this level of detail and a
little more detail, and then write several new functions for
implementing parts of it. I had until recently been thinking that I
would be able to re-work most of the existing functions to accomodate
what we need, and I have made some improvements along the way, but
that is proving too difficult. (I started making some notes in
<http://wiki.apache.org/subversion/MergeCodeImprovements> about things
that I think we should be looking to change in the existing merge
code.)
At this point I haven't included processing of subtree mergeinfo in
the algorithm description, though I have that in mind too.
Hi Julian,
So what is your plan for dealing with subtree mergeinfo then?
Implement the following then try to deal with it? Or get agreement on
what you have here then try to add that on? I worry about proceeding
to far without considering how subtree mergeinfo will be handled,
since most of the difficulties with and subsequent improvements to
merge tracking since 1.5 related to subtree mergeinfo.
And what about other merge "edge" cases, e.g. shallow merges, shallow
merge targets, merge targets with missing subtrees (due to switches or
authz restrictions). Just some things to keep in mind (FWIW the merge
test coverage is pretty thorough in these areas so breakage will be
obvious).
Paul
I don't think there should be any implementation of subtree merge in the
new symmetric merge. The new merge will still be very useful, even if it
halts with a message after finding subtree merginfo.
Here are three arguments against subtree merge:
1) My interpretation of the issue log agrees with Paul's observation
that a high proportion of bugs and implementation problems during the
past four years have come from subtree merge. This is a waste of talent
and is holding back progress in other areas.
2) It is not clear that there is any algorithm (given current tracking
data) that can correctly merge branches where subtrees are at different
revisions. Why beat your head against a brick wall?
3) It's apparently a bad idea for users to be maintaining subtree
merges. The existing subversion documentation recommends against it.
I think that the algorithm that Julian proposed for finding the latest
synced revision will work when the merges are only going between A and
B. This simplifies a lot of good workflows. Would it make sense to add
more information, such as the actual merge history, so that you would
know about other merge routes? I think it would be required
eventually. Merginfo does not contain very much information.
As a first step, does it make sense get this working completely without
cherrypicks? This will give us a easy-to-use merge which halts if it
finds cherrypicks or subtree merginfo, and which could be confused if
there are merges through a third branch. However, it will be a nice
improvement of the typical case where you are moving things between
trunk and a feature branch.
--
Andy Singleton
Assembla
