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
