On Thu, Nov 10, 2016 at 07:34:09PM +0300, Evgeny Kotkov wrote: > Here is the patch. Not sure that I fully understand the point about the > number of iterations, though ;)
Ah, yes. I see what you're doing. Unravelling the accept arg during the conflict walk instead of before the walk is very nice. To explain where my scepticism came from: Historically the conflict walker was inside libsvn_wc, and this code evolved from there. It was difficult to do what you're doing now before we created a new 1.10 conflict walker separate from the walker in the libsvn_wc library. In the early stages of 1.10 conflict development the walk inside libsvn_wc was supporting both 1.9 and 1.10 clients, so the new conflict code had to deal with whatever values clients were passing in via the legacy conflict callback. Which is also why the initial set of svn_client_conflict_option_t values were deliberately aligned with svn_wc_conflict_choice_t. Since 1.9 clients will still be supported by the libsvn_wc library and will keep getting the same semantics, I don't see any backwards compat concern which my brain somehow thought was still there. What is kind of annoying is that libsvn_client is still transforming option_id inputs back to accept-style arguments for libsvn_wc, at least for text and prop conflicts. But changing that is a huge effort. 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? Great work :)