On 7/9/07, Daniel Rall <dlr@collab.net> wrote:
> On Thu, 28 Jun 2007, Ben Collins-Sussman 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?
> >
> > Ah, great idea. That's a vital tool, indeed.
>
> 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.
>
> I can pass the memory address of the adm_access into Java-land as a
> long, but it's basically useless to everything except other JNI code
> written against the Subversion bindings. Pure Java code (e.g. SVNKit)
> would find this memory address to be completely useless.
>
> 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? 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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 22:57:31 2007