On Tue, 23 Oct 2007, Stefan Küng wrote:
> Mark Phippard wrote:
> >>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:
> >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
SVN_ERR(conflict_func(&result, &cdesc, conflict_baton, pool));
if (result == NULL)
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.
public ConflictResult resolve(ConflictDescriptor descrip)
return new ConflictResult(ConflictResult.chooseTheirs,
Something must be going haywire either in the marshalling of
calls/data through JNI glue, or in the Subversion libraries.
Received on Tue Oct 23 20:40:07 2007
- application/pgp-signature attachment: stored