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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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