[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Fri, 14 Oct 2016 18:24:05 +0200

Stefan Hett <luke1410_at_apache.org> writes:

> if (option == NULL)
> - return svn_error_createf(SVN_ERR_CLIENT_CONFLICT_OPTION_NOT_APPLICABLE,
> - NULL,
> - _("Inapplicable conflict resolution option "
> - "given for conflicted path '%s'"),
> - svn_dirent_local_style(conflict->local_abspath,
> - scratch_pool));
> + {
> + if (option_id == svn_client_conflict_option_merged_text) {
> + mime_type = svn_client_conflict_text_get_mime_type(conflict);
> + if (mime_type && svn_mime_type_is_binary(mime_type))
> + option = svn_client_conflict_option_find_by_id(resolution_options,
> + svn_client_conflict_option_working_text);
> + }
> + }

Looks like the indentation and the brace formatting are broken here and
in the next hunk.

> +
> + if (option == NULL)
> + return svn_error_createf(SVN_ERR_CLIENT_CONFLICT_OPTION_NOT_APPLICABLE,
> + NULL,
> + _("Inapplicable conflict resolution option "
> + "given for conflicted path '%s'"),

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().

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.

Regards,
Evgeny Kotkov
Received on 2016-10-14 18:24:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.