Stefan Sperling <s...@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

Reply via email to