On Wed, 2006-03-15 at 17:07 -0800, Daniel Rall wrote:
> I have one main objection, which is easily rectifiable: this function
> isn't specific to the client library, but part of the utility library
> (declared in svn_path.h).
>
> AFAICT, there's only one other set of APIs on the SVNClient JNI
> binding which doesn't belong to the client library:
> getAdminDirectoryName() and setAdminDirectoryName().
>
> I'd prefer to create a separate JNI binding which exposes a native API
> on a new class (maybe org.tigris.subversion.Path?). Thoughts?
If you mean create a new binding, org.tigris.subversion.javahl.Path, and
expose these 3 apis there, then I might suggest that the JNI binding be
a little more generic. The native apis that getAdminDirectoryName() and
setAdminDirectoryName() call (svn_wc_get_adm_dir and svn_wc_set_adm_dir)
are in libsvn_wc (svn_wc.h). Perhaps we should create a utility binding
(maybe org.tigris.subversion.javahl.SVNUtility), and put these 3 utility
apis in it.
>
>
> > with the following log message:
> >
> > Add isValidPath javahl api. The native java method calls
> > svn_path_check_valid and returns a jboolean of true if the return value
> > of svn_path_check_valid is SVN_NO_ERROR. The error message does not
> > appear to be l10n/i18n so I have localized my own message in CEE.
>
> You can leave out the bit about localization and CEE, and focus on
> behavior and implementation in the change summary. The gory details
> should show up below, in the per-file/symbol portion of the change
> log.
Sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 16 03:41:39 2006