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