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?
