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

Re: JavaHL bindings for the conflict resolution callback API

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-07-10 00:19:15 CEST

On Mon, 09 Jul 2007, Mark Phippard wrote:

> On 7/9/07, Daniel Rall <dlr@collab.net> wrote:
> >> On 6/28/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> >>
> >> >> I like the concept, but in addition to putting a "path" into the
> >> >> svn_client_conflict_description_t, I'd recommend putting an
> >"adm_access"
> >> >> baton. Otherwise, won't callback implementers will be lacking a vital
> >> >tool
> >> >> for working copy manipulation?
> >While implementing conflict resoultion callback bindings for JavaHL, I
> >ran into a bit of a snafu with regard to this key data structure:
> >JavaHL does not wrap libsvn_wc; it stops at libsvn_client.
> >Am I going to need to wrap parts of libsvn_wc for JavaHL to make
> >proper use of the conflict resolution callback? If so, which bits are
> >important?
> I do not understand why you would need to. Can't you just "swallow"
> that parm in the C++ code and not even expose it to Java?

Sure -- this is the approach I took last Friday.

> It seems like the Java code just needs to be able to set a return
> value if it wants the caller to do something. Otherwise it is up to
> the Java code to take the other parms it will get and do something.

For some reason I was under the impression that when the callback
returned a result like svn_wc_conflict_result_resolved (that's
"resolveD", as in "I already did it"), that it was up to the callback
itself to perform the resolution. However, after examining the code
in libsvn_wc/merge.c:svn_wc__merge_internal(), this does not seem to
be the case. This is Good -- looks like the WC merge handling paired
with the new svn_wc_conflict_result_t code should be sufficient for
JavaHL's use cases.

  • application/pgp-signature attachment: stored
Received on Tue Jul 10 00:18:49 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.