1.9-rc1: Javahl compilation issue in RHEL3

Compiling 1.9.0-rc1 JavaHL in RHEL3 32bit with GCC version 3.2.3-53 and libstdc++ version 5.0.3 fails with multiple compilation error in javahl/native/EditorProxy.cpp. In addition to line number 213, line 360 also fails with same error. However I was able to successfully compile against GCC 4.

Re: 1.9 JavaHL memory leak in ISVNRemote#status

On 22.03.2015 05:06, Branko Čibej wrote: > On 21.03.2015 16:23, Branko Čibej wrote: >> On 19.03.2015 11:43, Marc Strapetz wrote: >>> Attached example performs an endless series of remote status against >>> the Subversion repository. When invoked with -Xmx24M, the VM will run >>> out of memory soon.

Re: Subversion 1.9: svn cp --pin-externals may produce dummy logentries

Bert Huijben wrote: > I don't think this is really a noop change. Most likely svnadmin dump will > show that it recorded a change on the fs layer. > > The replay API (such as used by svnsync and svnrdump) probably won't show a > change. Erm... but that's basically what 'no-op change' means, to me:

Re: 1.9: javahl.ISVNClient#cleanup(String) always fails with "Attemptedto lock an already-locked dir"

On 23.04.2015 18:03, Bert Huijben wrote: > Yes, break locks should be default (as it was in older versions). An > unsafe default > > Bert > > From: Marc Strapetz > Sent: ‎23-‎4-‎2015 16:4

RE: 1.9: javahl.ISVNClient#cleanup(String) always fails with "Attemptedto lock an already-locked dir"

Yes, break locks should be default (as it was in older versions). An unsafe default Bert -Original Message- From: "Marc Strapetz" Sent: ‎23-‎4-‎2015 16:44 To: "dev@subversion.apache.org" Subject: 1.9: javahl.ISVNClient#cleanup(String) always fails with "Attemptedto lock an already

RE: Subversion 1.9: svn cp --pin-externals may produce dummy logentries

I don't think this is really a noop change. Most likely svnadmin dump will show that it recorded a change on the fs layer. The replay API (such as used by svnsync and svnrdump) probably won't show a change. Bert -Original Message- From: "Stefan Sperling" Sent: ‎23-‎4-‎2015 11:27 To: "

Re: RFE: copy with metadataOnly should allow removed/replaced sources and added/replaced targets

On 23.04.2015 16:59, Julian Foad wrote: Marc Strapetz wrote: Using copy with the new metadataOnly option (through the API) only allows to "move" or "copy" a missing file onto an unversioned file. It could also be helpful to copy/move metadata from a removed (or replaced) source to an already add

Re: RFE: copy with metadataOnly should allow removed/replaced sources and added/replaced targets

On 23.04.2015 16:01, Branko Čibej wrote: On 22.04.2015 20:28, Marc Strapetz wrote: Using copy with the new metadataOnly option (through the API) only allows to "move" or "copy" a missing file onto an unversioned file. It could also be helpful to copy/move metadata from a removed (or replaced) so

Re: RFE: copy with metadataOnly should allow removed/replaced sources and added/replaced targets

Marc Strapetz wrote: > Using copy with the new metadataOnly option (through the API) only allows to > "move" or "copy" a missing file onto an unversioned file. It could also be > helpful to copy/move metadata from a removed (or replaced) source to an > already added (or replaced) target. > > > Use

1.9: javahl.ISVNClient#cleanup(String) always fails with "Attempted to lock an already-locked dir"

cleanup-related code which is working fine with 1.8 JavaHL starts failing with 1.9 JavaHL. According to the docs, ISVNClient#cleanup(String) does not break locks, which seems to cause the problems: /** * Recursively cleans up a local directory, finishing any * incomplete operations, r

Re: RFE: copy with metadataOnly should allow removed/replaced sources and added/replaced targets

On 22.04.2015 20:28, Marc Strapetz wrote: > Using copy with the new metadataOnly option (through the API) only > allows to "move" or "copy" a missing file onto an unversioned file. It > could also be helpful to copy/move metadata from a removed (or > replaced) source to an already added (or replace

Re: Subversion 1.9: svn cp --pin-externals may produce dummy log entries

On 23.04.2015 11:27, Stefan Sperling wrote: > On Wed, Apr 22, 2015 at 07:58:35PM +0200, Marc Strapetz wrote: >> After invoking following series of commands: >> >> svnadmin create repo >> svn checkout file://localhost/d:/temp/externals/repo wc >> >> mkdir wc >> cd wc >> mkdir ext >> touc

Re: Subversion 1.9: svn cp --pin-externals may produce dummy log entries

On 23.04.2015 11:27, Stefan Sperling wrote: On Wed, Apr 22, 2015 at 07:58:35PM +0200, Marc Strapetz wrote: $ svn proplist -r2 -R -v ^/ ... Properties on 'file://localhost/D:/temp/externals/repo/dst/dir': svn:externals ^/ext@1 ext $ svn proplist -r1 -R -v ^/ ... Properties on 'file://lo

Re: svn commit: r1664596 - /subversion/trunk/subversion/libsvn_subr/config_win.c

On 15 April 2015 at 20:33, Ivan Zhakov wrote: > On 6 March 2015 at 15:02, wrote: >> >> Author: rhuijben >> Date: Fri Mar 6 12:02:30 2015 >> New Revision: 1664596 >> >> URL: http://svn.apache.org/r1664596 >> Log: >> * subversion/libsvn_subr/config_win.c >> (svn_config__parse_registry): Hide the

Re: Subversion 1.9: svn cp --pin-externals may produce dummy log entries

Stefan Sperling wrote: > Marc Strapetz wrote: >> Changed paths: >>A /dst (from /src:1) >>M /dst/dir [...] >> However, there is no modification expected, [...] > > Interesting. I suspect this comes about because the pin-externals code > always sends a propchange in the commit transaction. Ap

Re: Subversion 1.9: svn cp --pin-externals may produce dummy log entries

On Wed, Apr 22, 2015 at 07:58:35PM +0200, Marc Strapetz wrote: > After invoking following series of commands: > > svnadmin create repo > svn checkout file://localhost/d:/temp/externals/repo wc > > mkdir wc > cd wc > mkdir ext > touch ext\file > > mkdir src\dir > svn add * > svn

Re: 1.9.0-rc1 up for testing/signing

On Tue, Apr 21, 2015 at 01:09:01PM -0700, Ben Reser wrote: > The 1.9.0-rc1 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > This being a rc1 it means that our soak peri