Re: Updating local-moves (was: svn commit: r1301390 ...)

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.
Received on 2012-03-16 17:52:25 CET