On Tue, Apr 17, 2012 at 11:52 AM, Andy Singleton <a...@assembla.com> wrote: > 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.
Hi Andy, My understanding is that the --symmetric option will eventually go away. If that is still the case, what happens to users who have subtree mergeinfo in their repositories (e.g. ourselves! svn.apache.org/repos/asf/subversion). Do merge tracking aware merges just stop working for them? Do we add a new option that uses the existing merge logic so they can continue to merge? > Here are three arguments against subtree merge: Do you mean subtree merges or merges to targets with subtree mergeinfo? > 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. FWIW pretty much all of these issues are fixed as of 1.7. OTOH it certainly does complicate the symmetric merge work. > 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. Do you mean our merge target is at mixed-revisions or that the target has subtrees with explicit mergeinfo such that different revision ranges are are required for different subtrees (and/or the root of the target)? > 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. Regardless, plenty of users have it now, we can't just ignore it or hope it goes away. > 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. +1 to doing away with --reintegrate and the keep-alive-dance, I'm on board with that goal. > Would it make sense to add more > information, such as the actual merge history, so that you would know about > other merge routes? I don't completely follow, what did you have in mind exactly? Paul > 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
