[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-07-09 22:57:55 CEST

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.

Mark Phippard
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

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.