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 :)
Received on 2016-11-10 18:27:35 CET