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

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 resolution option in svn_client_conflict_text_get_resolution_options().

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 only because
we have to remain compatible with the old conflict system somehow.

> I think that a better way would be to handle this case in the command line
> by using svn_client_conflict_option_working_text for binary files, if
> we run with --accept=working.

Then try out your idea and show us your diff ;-)
Stefan has already gone through several iterations of this patch,
so I'd rather not ask him to revisit this again.

I think a little text/binary conflict style problem isn't worth worrying
about while several important tree conflict resolution options remain
unimplemented.
Received on 2016-11-10 10:31:09 CET