Re: Pretty definite bug in 1.7.0 and beyond for JavaHL SVNClient propertyGet (legacy tigris package)

Looking at 1.6.23 code [1,2,3,4] the behavior of the propertyGet method was to return null rather than instance of PropertyData under following conditions: * Property is absent * Value of the property is absent * Any exceptions occurred while PropertyData object was being constructed in native cod

[JavaHL] Reported incompatibility

Hi All, I came across a bug in one of the Atlassian tools that suggests that there was an API compatibility break in the JavaHL between versions 1.6 and 1.7. I am not sure when/if I get time to look more into it, therefore I am sharing with the group meanwhile. The following comment is from the i

Re: [PATCH] implement keywords substitution in mod_dav_svn

On Fri, Mar 8, 2013 at 2:24 PM, Ben Reser wrote: > On Fri, Mar 8, 2013 at 11:12 AM, Vladimir Berezniker > wrote: > > If someone does not mind explaining. What would be the benefit of having > > this decision be made by the server vs the client having to request that &g

Re: [PATCH] implement keywords substitution in mod_dav_svn

If someone does not mind explaining. What would be the benefit of having this decision be made by the server vs the client having to request that via a explicit parameter on the request? Thank you, Vladimir On Thu, Mar 7, 2013 at 3:41 PM, Daniel Shahaf wrote: > C. Michael Pilato wrote on Thu,

Re: Re[2]: [PATCH] implement keywords substitution in mod_dav_svn

Have not read through the whole thread, but why not make intent (that keyword substitution is desired) explicit rather than implicit (based on type of the client). E.g. send a flag with request indicating that substitution is desired on the server side: keyword=substitute, or if you wanted to get m

Nested working copies in SVN 1.7.x+ question

Hi All, I ran into some issues with SVN tests for JavaHL, as test WCs end up nested within the branch WC. So I am curious to understand what the official stance is, are nested working copies a supported use case? If this use case is supported please find below a theoretical problem(s) I mention

Re: [PATCH] JavaHL propertyGet handling in org.tigris.subversion package

Hi Conor, The org.tigris.subversion classes have been superseded by the ones in the org.apache.subversion from what I know. If you take a look at SVNClient class there you will notice that the method has the following signature: public native byte[] propertyGet(String path, String name, Revi

Re: Auto Upgrade Behavior

In my experience (I work in finance/banking sector), the issue with WC upgrades tend to come from reliance on multiple tools: cmd line - for scripts IDE plugin - for development plugin for the file explorer - for task that are quicker done outside IDE Continuous Integration plugin in "enterprise"

Vladimir's Status

Hi All, Just wanted to let you know that I did not forget about the javahl-ra branch and most likely be able to get back to it towards the end of September. But at the moment $DAYJOB does not leave me with sufficient free time to work on other projects. Regards, Vladimir

Re: Ev2 design questions

On Tue, Jun 26, 2012 at 10:21 PM, Hyrum K Wright wrote: > On Tue, Jun 26, 2012 at 7:10 PM, Vladimir Berezniker > wrote: >> On Tue, Jun 26, 2012 at 3:17 PM, Hyrum K Wright >> wrote: >>> On Sun, Jun 24, 2012 at 6:09 PM, Vladimir Berezniker >>> wrote: >>

Re: [RFC] JavaHL: Moving some of the C++ object address logic into Java

On Tue, Jun 26, 2012 at 3:18 PM, Hyrum K Wright wrote: > On Sun, Jun 24, 2012 at 9:20 PM, Vladimir Berezniker > wrote: >> Hi All, >> >> In the current JavaHL code the C++ objects are attached via pointer stored in >> the long cppAddr field in java object.  The

Re: Ev2 design questions

On Tue, Jun 26, 2012 at 3:17 PM, Hyrum K Wright wrote: > On Sun, Jun 24, 2012 at 6:09 PM, Vladimir Berezniker > wrote: >> Hi All, >> >> I have been taking a peek at ev2 code to see what it would take for JavaHL >> implementation and I have following questions

[RFC] JavaHL: Moving some of the C++ object address logic into Java

Hi All, In the current JavaHL code the C++ objects are attached via pointer stored in the long cppAddr field in java object. The way C++ code gets hold of the cppAddr value is to read this field using the GetLongField(). In summary Java: class JHLClass { long cppAddr; public native method()

[PATCH] JavaHL: Support commit callback across method invocations

In case of delta editor, commit callback is provided at the time of the editor creation and used during the close_edit() call. For that there is a need to keep a global reference to the underlying java object so that it does not get GCed meanwhile. Attached please find the patch that adds such cap

Re: [RFC] Passing invalid uri to svn_ra_reparent causes JVM to abort when using JavaHL library (javahl-ra branch)

I am not saying that it how it should be, just that is the behavior I would have expected from JavaHL if I was a user of it. > > > >     Bert > Thank you for your help, Vladimir > > > From: vladi...@berezniker.com [mailto:vladi...@berezniker.com] On Beha

Ev2 design questions

Hi All, I have been taking a peek at ev2 code to see what it would take for JavaHL implementation and I have following questions that do not seem do be covered by the docs: * svn_ra__get_commit_ev2() takes svn_cancel_func_t as a parameter, however session already has a cancellation callba

[RFC] Passing invalid uri to svn_ra_reparent causes JVM to abort when using JavaHL library (javahl-ra branch)

Hi All, While implementing svn_ra_reparent() function in JavaHL, I created a test that sends string "BAD" uri to the reparent function (I am trying to make sure JavaHL can't take the JVM down). This causes segfault inside uri_skip_ancestor() function of the line 1483 of the dirent_uri.c file:

Re: svn commit: r1352400 - in /subversion/branches/javahl-ra/subversion/bindings/javahl: native/SVNBase.cpp native/SVNBase.h src/org/apache/subversion/javahl/JNIObject.java

On Thu, Jun 21, 2012 at 1:43 PM, Blair Zajac wrote: > On 06/20/2012 08:34 PM, v...@apache.org wrote: > >> Author: vmpn >> Date: Thu Jun 21 03:34:05 2012 >> New Revision: 1352400 >> >> URL: >> http://svn.apache.org/viewvc?**rev=1352400&view=rev >

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Thu, Jun 14, 2012 at 8:40 AM, Vladimir Berezniker wrote: > > > On Thu, Jun 14, 2012 at 8:13 AM, Hyrum K Wright > wrote: > >> On Mon, Jun 11, 2012 at 2:39 PM, Vladimir Berezniker >> wrote: >> > >> > >> > On Mon, Jun 11, 2012 at

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Fri, Jun 15, 2012 at 5:44 AM, Mat Booth wrote: > On 14 June 2012 13:12, Vladimir Berezniker wrote: > > > > > > > > On Thu, Jun 14, 2012 at 4:37 AM, Hyrum K Wright < > hyrum.wri...@wandisco.com> wrote: > >> > >> On Thu, Jun 14, 2012 at 1

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Thu, Jun 14, 2012 at 8:48 AM, Hyrum K Wright wrote: > On Thu, Jun 14, 2012 at 2:40 PM, Vladimir Berezniker > wrote: > > > > > > On Thu, Jun 14, 2012 at 8:13 AM, Hyrum K Wright < > hyrum.wri...@wandisco.com> > > wrote: > >> * We're in

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

Sorry missed bunch of inline responses first time around. not used to this in gmail. On Thu, Jun 14, 2012 at 8:13 AM, Hyrum K Wright wrote: > On Mon, Jun 11, 2012 at 2:39 PM, Vladimir Berezniker > wrote: > > > > > > On Mon, Jun 11, 2012 at 6:20 AM, Hyrum K Wright <

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Thu, Jun 14, 2012 at 8:13 AM, Hyrum K Wright wrote: > On Mon, Jun 11, 2012 at 2:39 PM, Vladimir Berezniker > wrote: > > > > > > On Mon, Jun 11, 2012 at 6:20 AM, Hyrum K Wright < > hyrum.wri...@wandisco.com> > > wrote: > >> > >> On Thu,

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Thu, Jun 14, 2012 at 4:37 AM, Hyrum K Wright wrote: > On Thu, Jun 14, 2012 at 10:16 AM, Mat Booth > wrote: > > On 12 June 2012 03:11, Vladimir Berezniker wrote: > >> > >> > >> On Mon, Jun 11, 2012 at 8:39 AM, Vladimir Berezniker < > v...@hitechma

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

(createCppBoundObject): New method for creating java objects linked to their C++ counterpart [ in subversion/bindings/javahl/src/org/tigris/subversion/javahl/ ] * JNIObject.java: Base class for JNI linked java objects ]]] Thank you, Vladimir On Mon, Jun 11, 2012 at 8:39 AM, Vladimir Berezniker wrote

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Mon, Jun 11, 2012 at 8:39 AM, Vladimir Berezniker wrote: > > > On Mon, Jun 11, 2012 at 6:20 AM, Hyrum K Wright > wrote: > >> On Thu, Jun 7, 2012 at 4:03 AM, Vladimir Berezniker >> wrote: >> > Hi All, >> > >> > The intention if this pat

Re: [PATCH] JavaHL: Factor out common context to be shared between SVNClient and SVNRa classes

On Mon, Jun 11, 2012 at 9:09 AM, Hyrum K Wright wrote: > On Mon, Jun 11, 2012 at 2:58 PM, Vladimir Berezniker > wrote: > > > > > > On Mon, Jun 11, 2012 at 6:56 AM, Hyrum K Wright < > hyrum.wri...@wandisco.com> > > wrote: > >> > >> On Thu,

Re: [PATCH] JavaHL: Factor out common context to be shared between SVNClient and SVNRa classes

On Mon, Jun 11, 2012 at 6:58 AM, Hyrum K Wright wrote: > On Mon, Jun 11, 2012 at 12:56 PM, Hyrum K Wright > wrote: > > On Thu, Jun 7, 2012 at 5:09 AM, Vladimir Berezniker > wrote: > >> Greetings, > >> > >> This patch signifies a point post which I

Re: [PATCH] JavaHL: Factor out common context to be shared between SVNClient and SVNRa classes

On Mon, Jun 11, 2012 at 6:56 AM, Hyrum K Wright wrote: > On Thu, Jun 7, 2012 at 5:09 AM, Vladimir Berezniker > wrote: > > Greetings, > > > > This patch signifies a point post which I can merge the existing logic on > > the > > javahl-ra branch with starting p

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

On Mon, Jun 11, 2012 at 6:20 AM, Hyrum K Wright wrote: > On Thu, Jun 7, 2012 at 4:03 AM, Vladimir Berezniker > wrote: > > Hi All, > > > > The intention if this patch is to introduce reusable logic for creating > java > > objects from within C++. This keeps objec

Re: [PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

++ counterpart [ in subversion/bindings/javahl/src/org/tigris/subversion/javahl/ ] * JNIObject.java: Base class for JNI linked java objects ]]] Regards, Vladimir On Wed, Jun 6, 2012 at 10:03 PM, Vladimir Berezniker wrote: > Hi All, > > The intention if this patch is to introduce reusable

[PATCH] JavaHL: New method for creating java objects linked to their C++ counterpart

Hi All, The intention if this patch is to introduce reusable logic for creating java objects from within C++. This keeps object creation logic fully within C++ while leaving to java the decision as to when they will be destroyed. It will be used by RA code to allocate container object for items l

Re: [PATCH] JavaHL: Add SVN_JNI_STRING macro to reduce amount of code necessary to declare JNIStringHolder and check for exceptions

return in case of exceptions ]]] Thank you, Vladimir On Fri, Jun 1, 2012 at 8:47 AM, Vladimir Berezniker wrote: > Please consider following patch for trunk: > > [[[ > JavaHL: Add SVN_JNI_STRING macro to reduce amount of code necessary to > declare > JNIStringHolder and ch

[PATCH] JavaHL: Support logging of the static method calls

[[[ JavaHL: Support logging of the static method calls [ in subversion/bindings/javahl/native ] * JNIStackElement.cpp (JNIStackElement): Add logic to deal with NULL jthis, which happens with static method calls ]]] Index: subversion/bindings/javahl/native/JNIStackElement.cpp ===

[PATCH] JavaHL: Add SVN_JNI_STRING macro to reduce amount of code necessary to declare JNIStringHolder and check for exceptions

Please consider following patch for trunk: [[[ JavaHL: Add SVN_JNI_STRING macro to reduce amount of code necessary to declare JNIStringHolder and check for exceptions [ in subversion/bindings/javahl/native ] * JNIStringHolder.h (SVN_JNI_STRING): New macro to declare JNIStringHolder local varia

Re: [PATCH] JavaHL: Reduce amount of duplicate code used to check C++ pointer extracted from the java object

] * JNIUtil.h (SVN_JNI_NULL_PTR_EX): parenthesize expr for safety (SVN_JNI_NULL_PTR_EX, SVN_JNI_ERR, POP_AND_RETURN): eliminate unnecessary whitespace after ret_val ]]] Regards, Vladimir On Thu, May 31, 2012 at 3:35 AM, Greg Stein wrote: > On Thu, May 31, 2012 at 12:43 AM, Vladi

Re: [PATCH] JavaHL: Reduce amount of duplicate code used to check C++ pointer extracted from the java object

I applied the patch to the javahl-ra branch instead of the trunk by mistake, is it ok if a cherry pick it onto trunk? Sorry about that, Vladimir On Thu, May 31, 2012 at 3:37 AM, Greg Stein wrote: > On Thu, May 31, 2012 at 3:35 AM, Greg Stein wrote: > >... > > Fix the above three problems, and

Re: [PATCH] JavaHL: Reduce amount of duplicate code used to check C++ pointer extracted from the java object

On Thu, May 31, 2012 at 3:35 AM, Greg Stein wrote: > On Thu, May 31, 2012 at 12:43 AM, Vladimir Berezniker > wrote: > > Patch 01 - Introduce macro > > > > [[[ > > JavaHL: Added CPPADDR_NULL_PTR macro to reduce amount of duplicate code > > checking C++ po

[PATCH] JavaHL: Reduce amount of duplicate code used to check C++ pointer extracted from the java object

Patch 01 - Introduce macro [[[ JavaHL: Added CPPADDR_NULL_PTR macro to reduce amount of duplicate code checking C++ pointer extracted from the java object [ in subversion/bindings/javahl/native ] * JNIUtil.h (CPPADDR_NULL_PTR): New macro to test for NULL pointer and raise java exception if

Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS

jac wrote: >> On 05/21/2012 04:18 AM, Vladimir Berezniker wrote: >>> >>> Hyrum, >>> >>> 4. Use runtime rather than checked exceptions. >>> >>> I strongly dislike checked exceptions in code paths where there is >>> no expected r

Re: svn commit: r1343456 - in /subversion/branches/javahl-ra/subversion/bindings/javahl/native: RevpropTable.cpp RevpropTable.h

I will do as @dev decides. But to give context, at the moment there are 14 patches with first two already committed to the branch (mea culpa). 3 of the patches require manual svn copy command to apply since svn patch does not support conveying copy operation in the patch. Please don't be alarmed

Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS

exceptions as SVNClient and then convert to unchecked as the next logical step. This will allow me to better understand impact on the code base. Thank you, Vladimir On Tue, May 29, 2012 at 8:32 PM, Blair Zajac wrote: > On 05/21/2012 04:18 AM, Vladimir Berezniker wrote: > >> Hyrum, >

Re: svn commit: r1343456 - in /subversion/branches/javahl-ra/subversion/bindings/javahl/native: RevpropTable.cpp RevpropTable.h

Hi Hyrum, I committed JavaHL re-factoring changes in r1343452 and r1343456 thinking that while they are generally applicable to JavaHL code, they won't be used by any other JavaHL code, so they should go on the branch. But on a second thought they are not tied to the new RA code, it just happens t

Re: [PATCH] JavaHL: Explicitly pass jobject jthis when processing dispose() call rather than stashing a reference in the SVNBase class where it can be missused later

/directory objects created by another editor. So I will go with this option for now. Regards, Vladimir On Fri, May 25, 2012 at 4:47 PM, Vladimir Berezniker wrote: > Object hold their baton. Editor object also holds the editor driver (if I > am understanding the terminology correctly

Re: [PATCH] JavaHL: Explicitly pass jobject jthis when processing dispose() call rather than stashing a reference in the SVNBase class where it can be missused later

bout maintaining the directory baton in the context > of something like an editor drive? > > -Hyrum > > On Fri, May 25, 2012 at 2:29 PM, Vladimir Berezniker > wrote: > > The reason they are long lived is because they are reusable. E.g. > directory > > can be used fo

Re: [PATCH] JavaHL: Explicitly pass jobject jthis when processing dispose() call rather than stashing a reference in the SVNBase class where it can be missused later

rue, it won't matter, since those objects would be pure Java > objects handled by the JVM. > > -Hyrum > > On Fri, May 25, 2012 at 12:35 PM, Vladimir Berezniker > wrote: > > Greetings, > > > > Currently SVNBase class uses a member variable jthis to hold a copy of

Re: svn commit: r1342676 - in /subversion/branches/javahl-ra/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/ tests/org/apache/subversion/javahl/

Fixed. The corrected commit message is now: [[[ On the javahl-ra branch: Brought RA implementation up to date with changes merged from trunk in r1329205 [in subversion/bindings/javahl/native] * SVNReposAccess.cpp (SVNReposAccess): Drop the global pool mutex as it is not necessary, as

[PATCH] JavaHL: Explicitly pass jobject jthis when processing dispose() call rather than stashing a reference in the SVNBase class where it can be missused later

Greetings, Currently SVNBase class uses a member variable jthis to hold a copy of jobject reference. This variable lives as long as SVNClient object lives, however, the reference itself is only valid during a single JNI call. To address this mismatch the attached patch passes the jobject referenc

Re: svn commit: r1342682 - /subversion/branches/javahl-ra/subversion/bindings/javahl/native/InputStream.cpp

t; to trunk. Thanks again for the patches! > > -Hyrum > > On Fri, May 25, 2012 at 11:39 AM, Vladimir Berezniker > wrote: > > As this change plus another one are beneficial for general JavaHL use, I > > will send them as patches on separate threads. > > > > Than

[PATCH] JavaHL: Fix return value from the java svn_stream_t read function to be compatible with the txdelta_next_window function

Greetings, While working on enhancements for JavaHL I ran into a problem implementing svn_txdelta_apply call because txdelta_next_window would segfault while trying to calculate the streams checksum. I traced it down to code in the InputStream.cpp that returns -1 when end of stream is reached. -1

Re: svn commit: r1342682 - /subversion/branches/javahl-ra/subversion/bindings/javahl/native/InputStream.cpp

As this change plus another one are beneficial for general JavaHL use, I will send them as patches on separate threads. Thank you for the guidance, Vladimir On Fri, May 25, 2012 at 12:06 PM, Hyrum K Wright wrote: > Is this change specific to the branch, or is is beneficial for general > JavaHL

Re: svn commit: r1340253 - /subversion/trunk/COMMITTERS

= > > --- subversion/trunk/COMMITTERS [UTF-8] (original) > > +++ subversion/trunk/COMMITTERS [UTF-8] Fri May 18 21:12:26 2012 > > @@ -201,6 +201,7 @@ giorgio_valoti Giorgio Valoti > br.) > >

Re: [RFC][PATCH 00/22] JavaHL Ra API Implementation

So what would be the next steps. Thank you, Vladimir On Tue, Apr 24, 2012 at 9:52 PM, Vladimir Berezniker wrote: > > > On Mon, Apr 23, 2012 at 10:03 AM, Hyrum K Wright < > hyrum.wri...@wandisco.com> wrote: > >> I haven't reviewed the patched, but some comments

Re: [RFC][PATCH 00/22] JavaHL Ra API Implementation

On Mon, Apr 23, 2012 at 10:03 AM, Hyrum K Wright wrote: > I haven't reviewed the patched, but some comments about the general ideas > below. > > On Sat, Apr 21, 2012 at 10:51 PM, Vladimir Berezniker > wrote: > > Hi All, > > > > I am sending patch series

[RFC][PATCH 22/22] JavaHL Ra API Implementation

[[[ JavaHL: Add unit tests for the Ra API [ in subversion/bindings/javahl/test/org/tigris/subversion/javahl/ ] * RaReadonlyTests.java: New readonly tests for the RA API * RaTests.java: New read/write tests for the RA API * RunTests.java (suite): Add the RaReadonlyTests

[RFC][PATCH 21/22] JavaHL Ra API Implementation

[[[ JavaHL: Expose additional methods publicly so that readonly tests can use them to setup a single shared readonly test repository to speed up tests [ in subversion/bindings/javahl/test/org/tigris/subversion/javahl/ ] * SVNTests.java: (USERNAME, PASSWORD): Make test username a

[RFC][PATCH 19/22] JavaHL Ra API Implementation

[[[ JavaHL: Include the new Ra java code in the build process * build.conf (options): Don't try to find new jni header files before they are generated (javahl-java): compile classes in the src/org/apache/subversion/javahl/ra directory (javahl-ra-javah): new section for ge

[RFC][PATCH 01/22] JavaHL Ra API Implementation

[[[ JavaHL: Fix return value from the java svn_stream_t read function to be compatible with the txdelta_next_window function [ in subversion/bindings/javahl/native ] * InputStream.cpp (read): Return 0 instead of -1 as expected by the txdelta_next_window function ]]] Index: subve

[RFC][PATCH 18/22] JavaHL Ra API Implementation

[[[ JavaHL: New Java classes exposing the Ra layer to java [ in subversion/bindings/javahl/src/org/tigris/subversion/javahl/ ] * JNIObject.java [ in subversion/bindings/javahl/src/org/tigris/subversion/javahl/ra ] * ISVNDirectory.java, ISVNEditor.java, ISVNFile.java, ISVNNod

[RFC][PATCH 17/22] JavaHL Ra API Implementation

[[[ JavaHL: Add support for marking object disposed without deleting it, used by the new Ra JNI code [ in subversion/bindings/javahl/native ] * SVNBase.cpp, SVNBase.h (markDisposed, assertNotDisposed, init): New function to support tracking disposal state of the object (AS

[RFC][PATCH 16/22] JavaHL Ra API Implementation

[[[ JavaHL: Add new method for creating new java objects connected to a matching C++ object [ in subversion/bindings/javahl/native ] * SVNBase.cpp, SVNBase.h (createCppBoundObject): New method for creating new java objects connected to a matching C++ object ]]] Index: subversion

[RFC][PATCH 15/22] JavaHL Ra API Implementation

[[[ JavaHL: Separated logic for clearing java object cppAddr into its own function as needed by the commit editor C++ objects that require the child to clear the reference and parent to perform deletion [ in subversion/bindings/javahl/native ] * SVNBase.cpp, SVNBase.h (dispose,

[RFC][PATCH 14/22] JavaHL Ra API Implementation

[[[ JavaHL: Added support for allocating SVNBase object from passed in pools rather than global pool, as needed by the Ra JNI implementation [ in subversion/bindings/javahl/native ] * SVNBase.cpp, SVNBase.h (SVNBase): Additional constructor taking a parent pool parameter ]]] Ind

[RFC][PATCH 13/22] JavaHL Ra API Implementation

[[[ JavaHL: Factor out common progress and cancellation callbacks as well as configuration and authentication context into CommonContext class from SVNClient specific code in the ClientContext class so that it can be shared with the Ra JNI code [ in subversion/bindings/javahl/native ]

[RFC][PATCH 12/22] JavaHL Ra API Implementation

[[[ JavaHL: Factor out common java string map processing into StringsTable class from svn_string_t specific processing in the RevpropTable class [ in subversion/bindings/javahl/native ] * StringsTable.cpp, StringsTable.h, RevpropTable.cpp, RevpropTable.h (m_revprops): Move m_rev

[RFC][PATCH 11/22] JavaHL Ra API Implementation

[[[ JavaHL: Added SVN_JNI_INPUT_STREAM macro to reduce amount of duplicate code dealing with InputStream wrapper and checking for exceptions [ in subversion/bindings/javahl/native ] * InputStream.h (SVN_JNI_INPUT_STREAM): New macro to declare local variable of type InputStream a

[RFC][PATCH 10/22] JavaHL Ra API Implementation

[[[ JavaHL: Added SVN_JNI_BYTE_ARRAY macro to reduce amount of duplicate code dealing with jbyteArray wrapper and checking for exceptions [ in subversion/bindings/javahl/native ] * JNIByteArray.h (SVN_JNI_BYTE_ARRAY): New macro to declare local variable of type JNIByteArray and

[RFC][PATCH 09/22] JavaHL Ra API Implementation

[[[ JavaHL: Added support for creating of svn_string_t from JNIByteArray [ in subversion/bindings/javahl/native ] * JNIByteArray.cpp, JNIByteArray.h (getLength): Mark as const as the function does not alter class data and can be used by other const functions (getSvnString)

[RFC][PATCH 08/22] JavaHL Ra API Implementation

[[[ JavaHL: Added SVN_JNI_STRING macro to reduce amount of duplicate code dealing with jstring wrapper and checking for exceptions [ in subversion/bindings/javahl/native ] * JNIStringHolder.h (SVN_JNI_STRING): New macro to declare JNIStringHolder local variable and return in cas

[RFC][PATCH 07/22] JavaHL Ra API Implementation

[[[ JavaHL: Added CPPADDR_NULL_PTR macro to reduce amount of duplicate code checking C++ pointer extracted from the java object [ in subversion/bindings/javahl/native ] * JNIUtil.h (CPPADDR_NULL_PTR): New macro to test for NULL pointer and raise java exception if necessary ]]] I

[RFC][PATCH 06/22] JavaHL Ra API Implementation

[[[ JavaHL: Support logging of the static method calls [ in subversion/bindings/javahl/native ] * JNIStackElement.cpp (JNIStackElement): Add logic to deal with NULL jthis, which happens with static method calls ]]] Index: subversion/bindings/javahl/native/JNIStackElement.cpp ===

[RFC][PATCH 05/22] JavaHL Ra API Implementation

[[[ JavaHL: Support keeping global reference to the callback java object as required by the RA API due to callback being used across method calls [ in subversion/bindings/javahl/native ] * CommitCallback.cpp, CommitCallback.h (CommitCallback, ~CommitCallback): Add handling of ad

[RFC][PATCH 04/22] JavaHL Ra API Implementation

[[[ JavaHL: Support returning non const, empty rather than NULL hash as required by (svn_ra_get_commit_editor3) apr_hash_t *revprop_table parameter [ in subversion/bindings/javahl/native ] * RevpropTable.cpp, RevpropTable.h (hash): Removed const qualifier and added bool nullIfEm

[RFC][PATCH 03/22] JavaHL Ra API Implementation

[[[ JavaHL: Factored out common context for later use by SVNRa class [ in subversion/bindings/javahl/src/org/tigris/subversion/javahl/ ] * CommonContext.java, SVNClient.java (ClientContext): Move to progress listener into CommonContext for later use by the new SVNRa class ]]] In

[RFC][PATCH 02/22] JavaHL Ra API Implementation

[[[ JavaHL: Explicitly pass jobject jthis when processing dispose() call rather than stashing a reference in the SVNBase class where it can be missused later [ in subversion/bindings/javahl/native ] * SVNBase.cpp, SVNBase.h (dispose, jthis): Accept jobject jthis as explicit para

[RFC][PATCH 00/22] JavaHL Ra API Implementation

Hi All, I am sending patch series that adds support for subset of SVN Ra layer to the JavaHL API. Initial goal was to expose commit editor APIs necessary to commit to the remote repositories without local working copy and then seek feedback before going further. While developing the prototype