On Thu, Jun 25, 2015 at 12:59:16PM +0000, Bert Huijben wrote:
> I think it would help future conflict resolve code if we call the conflict resolver only once per conflicted path. This would allow providing all conflict details (<text, prop> | <tree>) to a user, which can then really apply resolve operations like all-theirs (knowing what the consequences are).
I agree this would be useful.
> I’m not sure if the 'svn_client_conflict_t’ really prepares for that situation, as it appears that it still assumes all conflict details may be different for multiple conflicts on a single path.
>
> I would think that you need two opaque types: one for the conflicted path (defining operation, reason, urls, etc.) and one for the individual conflicts that apply to the path (text, properties, tc specific details)
>
We can make this happen by adding a new interface. For example, we could
have a function such as this one, as I suggested in
http://mail-archives.apache.org/mod_mbox/subversion-dev/201505.mbox/%3C20150529111601.GO18563@ted.stsp.name%3E
/**
* Indicate the types of conflicts present on the working copy node
* described by @a conflict. Any output argument may be @c NULL if
* the caller is not interested in the status of a particular type.
*
* While multiple text and/or property changes may exist, only one
* tree conflict can be recorded on a node.
*
* @since New in 1.10.
*/
svn_error_t *
svn_client_conflict_get_types(svn_boolean_t *has_text_conflicts,
svn_boolean_t *has_prop_conflicts,
svn_boolean_t *has_tree_conflict,
svn_wc_client_conflic_t *conflict,
apr_pool_t *scratch_pool);
We're now at the point where we can add pretty much anything we
would want to the resolver.
Note that the current functionality is only based on the semantics used by
svn_wc_conflict_description2 because I want to allow a smooth transition
from svn_wc_conflict_description2 into the new world.
> A default implementation would then be able to callback to the current once per conflict callbacks, while new implementations can use all information at once.
The callback is essentially only used to implement a loop over all
conflicts in the working copy. For now, I want to focus on resolving
conflicts on a given single path, without using the callback.
My current plan is to introduce a temporary special code path for
'svn resolve' which runs new resolver code -- e.g. when only one path
is given to 'svn resolve' and no specific options, we run the new code.
This way, we can play with new ideas without breaking tests and without
breaking functionality for those of us using trunk clients for development.
BTW, Julian and Philip helped me a lot with coming up with this plan
by discussing various ideas with me here in Laško.
Received on 2015-06-25 15:29:03 CEST