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

Re: [PATCH] Suppress conflict resolver in dry-run merge

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 1 Nov 2018 17:25:10 +0100

On Thu, Nov 01, 2018 at 10:32:56AM +0000, Jonathan Guy wrote:
> Ok I looked into this a bit more and I see what's going on now.
> The post merge conflict resolver runs because the merge operation reported conflicts (via the conflict stats).
> This calls
> svn_client_conflict_walk
> which calls
> svn_wc_walk_status
> which reports no conflict at that path because the wc was never changed because it was a dry run. So the whole operation gets dropped here.
> I’m still convinced the whole thing is a pointless exercise.
> A dry-run merge will not produce any actual conflicts on-disk so the resolver will never do anything.
> I guess there could be other reasons I don’t know of to run the resolver so we’ll just leave it as is.
> Thanks again for your time.

Thanks for digging into this further.

I think you are raising a good point. The fact that it works as expected
right now is due to a side-effect. So your proposed change is still worth
some consideration.

While many SVN operations support a dry-run mode, at present the conflict
resolver does not. It might actually be nice to see what the resolver would
do while in dry-run mode. A dry-run merge could show the result of successful
resolution in cases where a recommended resolution option exists, rather
than showing a conflict. For instance, a merge to the new location of a
moved item could be shown, instead of showing a conflict at the old location.
This would require some work in the conflict resolver which would mostly
be trivial; it's just that there's a lot of code in the resolver so
completing even trivial changes in a consistent manner takes time.

Until the resolver grows such a dry-run mode I think your patch makes sense.
Do we agree here?
Received on 2018-11-01 17:25:31 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.