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.
-Hyrum
Received on 2008-03-26 19:57:35 CET