On 01.11.2018 17:25, Stefan Sperling wrote:
> 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.
Wouldn't that only work if the nature of the conflict was recorded
somewhere in the working copy? And wouldn't recording it be exactly
opposite of what 'svn merge --dry-run' really means?
On the other hand, we've had requests for 'svn merge --dry-run' to show
potential text conflicts and even launch an external diff or merge tool
to display them. So there's clearly room for these kinds of features.
Maybe a '--moist-run' option is what we need. :)
-- Brane
Received on 2018-11-01 17:38:58 CET