Re: problem/bug with conflict callback

On Tue, 23 Oct 2007, Stefan Küng wrote:

> Mark Phippard wrote:
> [snip]
> >>The last merge command results in a property conflict, but the conflict
> >>resolution callback is not invoked.
> >
> >Are regular conflicts still using the callback? I ask because the
> >JavaHL tests are currently failing in a way that implies the callback
> >is not getting called:
> >
> >There was 1 error:
> >1)
> >testBasicConflict(org.tigris.subversion.javahl.BasicTests)org.tigris.subversi
> >on.javahl.ClientException: Conflict resolution failed
> >svn: Conflict callback violated API: returned no results.
>
> Yes, the callback gets invoked properly for file conflicts.

Mark, I'm also seeing this error (Mac OS X). Bah, I had all the tests
passing before SubConf. It looks like Ben's latest batch of conflict
resolution callback changes -- coupled with my attempts to keep the
JavaHL bindings up to date -- caused this. The failure is coming from
subversion/libsvn_wc/svn_wc__merge_internal(), here:

              SVN_ERR(conflict_func(&result, &cdesc, conflict_baton, pool));
              if (result == NULL)
                return svn_error_create(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE,
                                        NULL, _("Conflict callback violated API:"
                                                " returned no results"));

Now, the conflict resolution callback in our test case always returns
a result (though, I wasn't sure what, if any mergedPath to specify):

    public void testMergeConflictResolution() throws Throwable
    {
        // Add a conflict resolution callback which always chooses the
        // user's version of a conflicted file.
        client.setConflictResolver(new ConflictResolverCallback()
            {
                public ConflictResult resolve(ConflictDescriptor descrip)
                {
                    return new ConflictResult(ConflictResult.chooseTheirs,
                                              null);
                }
            });

        ...

Something must be going haywire either in the marshalling of
calls/data through JNI glue, or in the Subversion libraries.