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