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

2016-11-11 Thread Evgeny Kotkov
Evgeny Kotkov writes: >> Great work :) > > Thanks. I'll commit the patch sometime tomorrow. Committed in r1769269. Regards, Evgeny Kotkov

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

2016-11-10 Thread Evgeny Kotkov
Stefan Sperling 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 adap

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

2016-11-10 Thread Stefan Sperling
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.

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

2016-11-10 Thread Evgeny Kotkov
Stefan Sperling writes: > There's a similar hack for resolving tree-conflicts with --mine-conflict, > which the client API does not expose as a valid option either. > > I'd say leave these as-is. We won't accumulate more such hacks. They > are clearly marked as hacks in comments, and they exist o

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

2016-11-10 Thread Stefan Sperling
On Fri, Oct 14, 2016 at 06:24:05PM +0200, Evgeny Kotkov wrote: > As for the change itself, I don't think that silently transforming one > conflict option id to another in svn_client_conflict_text_resolve_by_id() > API is a proper thing to do, because we don't expose this option id as a > viable res

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

2016-11-09 Thread Stefan
Hi Evgeny, it took me a while to get back to this, since I find it still quite challenging to get my head into this part of the SVN design and needed some uninterrupted time to fully focus on this topic. On 10/14/2016 18:24, Evgeny Kotkov wrote: > Stefan Hett writes: > >> [...] On the indentati

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

2016-10-18 Thread Stefan Hett
Just a quick heads up since I didn't get to reply to this one yet: Thanks for your review, Evgeny. On 10/14/2016 6:24 PM, Evgeny Kotkov wrote: Stefan Hett writes: if (option == NULL) -return svn_error_createf(SVN_ERR_CLIENT_CONFLICT_OPTION_NOT_APPLICABLE, -

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

2016-10-14 Thread Evgeny Kotkov
Stefan Hett writes: >if (option == NULL) > -return svn_error_createf(SVN_ERR_CLIENT_CONFLICT_OPTION_NOT_APPLICABLE, > - NULL, > - _("Inapplicable conflict resolution option " > - "given for conflicted pa