[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 16 Mar 2012 14:26:09 -0400

On Fri, Mar 16, 2012 at 12:51, Stefan Sperling <stsp_at_elego.de> wrote:
>...
> 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.

Ah... now this is a fair point. Moving away from theory to pragmatism.
It sounded like you didn't like the theory; but maybe you were just
more concerned about "what we have now" ??

I think this leads to leaving the code as-is, or yanking it in favor
of some kind of notification/conflict. The former is "no more work",
but does it paint us into any sort of corner to do this Right later?
The latter is some more coding work, and certainly more work for the
users in the typical use case.

So. Will this "auto apply" get us into trouble today? Will somebody
say "holy crap! why did you touch my file! I moved it away so you
wouldn't do that!". Maybe the response is, "known issue. apply a
reverse merge to back out that change in your move-dest."

Second, in the future, when we turn this into raising a conflict, will
it make people cranky? "Hey! that used to work without input! you're
pissing me off."

Thoughts?

Cheers,
-g
Received on 2012-03-16 19:26:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.