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

Re: [PATCH]Can we accept JavaHL Revison.Number.Number(-1)?

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 26 Mar 2008 15:10:58 -0400

On Wed, Mar 26, 2008 at 2:57 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Kamesh Jayachandran wrote:
> >> Mark Phippard wrote:
> >>> Maybe the underlying native API you want to call supports this
> >>> functionality and there are internal cases where it is used or needed,
> >>> but before we expose this to users via JavaHL I think we should
> >>> understand why we would want to. I notice the native API is a double
> >>> underscore, so maybe that is a good sign that it is not correct to
> >>> expose this as is. Why not just have an API like this that is
> >>> exposed?
> >>>
> >>> /**
> >>> * Returns the youngest revision number for path.
> >>> * @since 1.6
> >>> */
> >>> public native long getYoungestRevisionNumber(String pathOrUrl);
> >>>
> >>> Internally, this could call the native API and hide the other details.
> >
> >> It would still need to call a public libsvn_client API, since the C++
> >> layer of the JavaHL bindings only has access to public APIs.
> >
> > If I understand correctly we can make use functions with '__' in their name from
> > other svn libraries from JavaHL as we already use such intra library functions
> > from libsvn_fs_util in libsvn_fs_(fs|base).
> Well, we don't currently do so anywhere in the C++ side of JavaHL, and
> I'm just a little leery of getting into that habit. I see the JavaHL
> bindings as just another consumer of the client API, which just happens
> to live in our repo; I don't see why it should get special privileges.
> This is completely orthogonal to the purpose of libsvn_fs_util.

I do not believe this will work anyway. On Windows, only the public
API is exported by the DLL interface, so I do not see how the JavaHL
code could access the private symbols.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-26 20:11:15 CET

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