OK, enabled in 1369896. --reintegrate forces a 1.7 reintegrate, unconditionally, at the moment; I haven't put a deprecation warning in there.
Please let me know if anyone sees unexpected results from merge now. TODO: * Revise 'svn merge' help text. * Checks for 'no local mods' and 'no switched subtrees' aren't currently being performed when they should; it needs to wait till after working out which kind of merge is required, and then do the strict checks iff it's reintegrate-like. * Check foreign-repos merges don't try to use the symmetric merge code path. * Add a JavaHL API version of svn_client_merge_symmetric(). * ambiguity: reintegrate or not (merge_symmetric_tests-18) Email thread "Symmetric merge and subtrees". * Issue #4217 -- reported rev unexpected (merge_tests-78) Email thread "Symmetric merge and deleted subtrees". - Julian ----- Original Message ----- > From: Julian Foad <julianf...@btopenworld.com> > To: Branko Čibej <br...@wandisco.com> > Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> > Sent: Monday, 6 August 2012, 10:23 > Subject: Re: Enabling symmetric merge, and UI details > > Branko Čibej wrote on 3 August 2012: > >> On 03.08.2012 21:51, Mark Phippard wrote: >>> On Fri, Aug 3, 2012 at 3:25 PM, Julian Foad wrote: >>>> * Make the '--reintegrate' option mean the user believes >>>> a reintegrate-style merge is needed, so check that the >>>> previous merge is as expected (that it, in the opposite >>>> direction) and bail out if not. >>> >>> Why do you want to do this? Just to educate the user that they do not >>> need reintegrate? It does not seem like it would be necessary. What >>> happens today if the user does this? I guess if --reintegrate does >>> the wrong thing today then this makes sense. But if it basically >>> still gives a valid result why bother to make a behavior change in >>> what is a deprecated option anyway? >> >> I concur. Our goal is to make the merge algorithm truly symmetric within >> the next release or two, inshallah. In order to get there, the behaviour >> of "svn merge" will certainly change in some scenarios, but we > obviously >> expect that the results will become more correct. As long as we can >> argue that any such changes in 1.8 are simply incremental adjustments on >> the way towards that goal, it seems a waste of effort to maintain any >> kind of special meaning for the --reintegrate option. >> >> IMO the only thing --reintegrate should do in 1.8 is to issue a warning >> about it being deprecated; and in 1.9 it we can silently ignore it. > > You mean --reintegrate should cause 'svn' to do a 1.7 reintegrate merge > (and issue a deprecation warning)? I don't have an opinion on the warning, > but doing an old-style reintegrate makes sense: there is no need to make the > behaviour of that option more complex like I was suggesting. > > - Julian
