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.
