On Fri, Aug 3, 2012 at 4:54 PM, Julian Foad <julianf...@btopenworld.com> wrote:
>> 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? > > Today, if the user gives the --reintegrate option when a non-reintegrate > merge is the appropriate one based on past > merges, Subversion goes through the motions of a reintegrate merge and > produces the wrong result. (Wrong in the > sense that it doesn't properly merge the sets of unique changes from the two > branches, not that it doesn't do > exactly what we taught it to do.) If it does the wrong thing today in this situation, then I am in favor of your proposal. >> Do you plan on adding a new mergeSync API to JavaHL or just have the >> JavaHL C++ code call the new API when the RevisionRange is passed as I >> noted above? I would be fine with the latter as I do not think it >> introduces any unexpected new behaviors. There is already a specific >> mergeReintegrate JavaHL API. > > I would prefer to add a new API to JavaHL, as the current merge API is > already way too overloaded with variations > of behaviour in my opinion. That is OK with me. Based on the existing signature I mentioned, it seems like the only option you would drop is the RevisionRange argument. I think when Hyrum cleaned up the JavaHL methods he just preferred to not have as many subtle variants of the method. Regardless which option you choose, I just wanted to be sure there was some way we can use the new API from JavaHL. Adjusting Subclipse to use the right method will be trivial. A couple of other comments: You do not mention explicit 2-URL merges but I assume those will be unchanged? You do not mention foreign repository merges. Perhaps the wiki does? -- Thanks Mark Phippard http://markphip.blogspot.com/
