Remove the svn_cl__conflict_func_interactive() callback.
The command line client will now start the conflict resolver by itself if an update, merge, or switch operation flags conflicts in the working copy. Before this commit it was relying on the libraries to do so. This finally gives full control over conflict resolution to the client and paves the way for future enhancements of the conflict resolver.
Only one use case of the libsvn_wc conflict callback remains. This is required for supporting 'svn merge --accept' during merges which perform multiple editor drives. A better solution would be changing the svn_client_merge API to allow the client to get away without the conflict callback. I've left this for future work.
* subversion/svn/cl.h (svn_cl__conflict_stats_get_paths): Declare this new function which is involved in keeping existing conflict resolution behaviour intact. The client already records newly conflicted paths as part of conflict accounting. We use this list of paths to run the conflict resolver on the newly conflicted paths only, rather than running it over the entire working copy as 'svn resolve' would do. (svn_cl__get_conflict_func_interactive_baton, svn_cl__conflict_func_interactive): Remove declaration. Now unused. (svn_cl__walk_conflicts): Declare this new function which makes the working copy walker logic of 'svn resolve' available to subcommands which now need it as well.
* subversion/svn/merge-cmd.c (conflict_func_merge_cmd_baton, conflict_func_merge_cmd): Add this temporary implementation of svn_wc_conflict_resolver_func2_t to avoid breaking 'svn merge --accept'. Note that we cannot support the 'edit' and 'launch' accept options anymore, so these now map to 'postpone'. This is a small CLI interface change relative to 1.9. (svn_cl__merge): Install the above conflict callback if necessary. Invoke the interactive conflict resolver if necessary.