On Fri, Mar 16, 2012 at 11:04:30AM -0400, Greg Stein wrote: > I've never suggested making users run 'svn merge' in this edit/move > conflict scenario.
As things stand, users out there must run 'svn merge' manually to apply these incoming edits. That is what I want to address. > The resolution process does that. In our fantasy, it does. But in reality it doesn't. The resolution process today is entirely manual. If there was already a resolver in place that did this, I wouldn't argue at all about showing these options to users. But we don't have it. And I doubt we'll have it in 1.8. > I just think a conflict should be recorded. We should not make assumptions > when an ambiguity arrives. I've posited two possible resolutions for an > edit/move conflict. Philip has posited even more outcomes. Version control > must be as deterministic as possible. Heuristics(*) are, by definition, > non-deterministic. Yes, that is the end goal. And once we've got all the underpinnings required to make it work this way, I agree that a prompt is a good idea. However, right now, I want reasonable behaviour with the tools we have available *today* -- Ev1, no conflict store, and interactive resolution while an update/merge is live. I don't want to wait until we've rewritten half of Subversion before making this small improvement for the 'incoming edit vs. local rename' case which we can already make today. And I've already implemented it so what you're suggesting either amounts to additional work in the current conflict resolver (ugh, I've tried that on the moves-scan-log branch, and it sucks), or reverting what I've already implemented. I think we agree on what the end goal is. We just don't seem to agree on temporary measures to ease some of the pain with conflicts that users suffer today until we reach that end goal.
