On 7/9/07, Daniel Rall <dlr@collab.net> wrote:
> 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.
Dan,
Trying to write an implementation of this callback in Subclipse and
having a few problems:
1) The callback method throws SubversionException. This has to be
changed as it is not possible for the implementation of the callback
to construct an object of that type. Also, since this is a callback
who is responsible for catching this exception? Shouldn't the return
value just indicate if there was an error?
2) What is with all of the usage of Object? Are those just place
holders for now and you are going to replace them with new classes you
need to create? As a user of the API I have no idea what I am
receiving in those parameters -- which seem like important parms, and
also I do not know what to return from the callback.
--
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 Tue Jul 10 16:14:10 2007