Re: svn commit: r1764902 - in /subversion/trunk/subversion: libsvn_client/conflicts.c svn/conflict-callbacks.c tests/cmdline/resolve_tests.py

Stefan Sperling <stsp_at_elego.de> writes:

> So basically the 1.10 svn client is now doing the reverse-mapping of
> conflict_option_id_to_wc_conflict_choice() in libsvn_client/conflicts.c
> with some extra tweaks.
> Perhaps other clients than the command line client won't have such
> problems, because they can adapt their end-user interfaces without
> worrying so much about existing scripts?

We are talking about third-party clients exposing options similar to
--accept=base/working/mine-conflict/... that would like to start using
the new API, right?

I don't see a big problem here. Since switching to the new API requires
changing the code, in the worst case developers could just do the same
thing as in svn_cl__resolve_conflict().

What I find important is keeping these kinds of mappings localized,
instead of doing one part in the command line client, and then fixing
things within the libsvn_client API. And I think the API shouldn't
contradict itself by allowing to pass an option id that isn't a part
of the allowed resolution options, and that it shouldn't be trying to
outsmart the user in this case.

> Great work :)

Thanks. I'll commit the patch sometime tomorrow.

Regards,
Evgeny Kotkov
Received on 2016-11-11 00:06:34 CET