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
