Daniel and Daniel, thanks for your replies. Responding in summary, after taking all your points and questions into consideration.
1. I agree with softening this to be a warning rather than a hard error in a patch release, and then a hard error in 1.15. I hadn't thought of doing a preprocessor-based time-bomb; good idea. I will retract my backport until I have done that. 2. Returning to 1.6/1.7 behaviour is not something to be aspired to. Never mind the reversion of the source:target comparison in 1.8 being accidental; at least in part, the omission of sufficient URL comparisons in the first place was accidental (the source1:source2 part), and even if some of the possible combinations of inputs "worked" in 1.6/1.7 we can agree for sure that the set of possible combinations is not well tested. 1.6/1.7 did not cleanly implement a policy of "URLs can differ as long as they point to the same or equivalent repositories". Rather it was, URLs can differ in the source:target inputs (but not the source1:source2 inputs) to certain merge entry points, in the sense that we don't reject this, and it may even partly or fully work with merge tracking merges, but we are not sure and nothing is tested except "foreign merge" cases. I wouldn't want to see us introduce any half-measure, but only a full policy of "we distinguish repositories by their UUID rather than any given URL, in all cases" which should include non-merge cases such as diff as well, and I think that is out of scope at the present time and investment level in Subversion; it would be a "Subversion 2" wish list item if we ever go there. (If you would like a specific answer to any of your specific points, would you kindly ask it/them again. Just picking up on one specific question, "how would a warning be more of a hindrance than a hard error?": I was thinking of two things. One: without seeing a warning at the top the first thing the user might see could be the scroll-by stopping at conflicts, and the user might then waste a lot of time resolving them. Two: having to revert a merge is in some cases non-trivial, if we not making assumptions about best practices and clean simple scenarios.) - Julian
