Mark Phippard wrote: > On Fri, Aug 3, 2012 at 4:54 PM, Julian Foad wrote: >> 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. [...] > > 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?
Correct: 2-URL merges are unchanged. > You do not mention foreign repository merges. Perhaps the wiki does? They are non-merge-tracking merges, and so should be unchanged. I will check whether that's correctly implemented. - Julian
