Re: svnmover feedback

2015-04-29 Thread Daniel Shahaf
Daniel Shahaf wrote on Wed, Apr 29, 2015 at 22:24:36 +: > Julian Foad wrote on Mon, Apr 27, 2015 at 20:58:34 +0100: > > Daniel Shahaf wrote: > > > Julian Foad wrote: > > >> On 17 April 2015, Daniel Shahaf wrote: > > > I suppose the answer depends on the properties, i.e., "interface", of > > > a

Re: svnmover feedback

2015-04-29 Thread Daniel Shahaf
Julian Foad wrote on Mon, Apr 27, 2015 at 20:58:34 +0100: > Daniel Shahaf wrote: > > Julian Foad wrote: > >> On 17 April 2015, Daniel Shahaf wrote: ... > > By the way, what's the relation between the "move tracking" part of the > > work and the "first-class branches" part? I think move-tracking is

Re: svn commit: r1676769 - /subversion/trunk/subversion/bindings/javahl/native/CreateJ.cpp

2015-04-29 Thread Branko Čibej
On 29.04.2015 19:44, Philip Martin wrote: > br...@apache.org writes: > >> Author: brane >> Date: Wed Apr 29 15:30:54 2015 >> New Revision: 1676769 >> >> URL: http://svn.apache.org/r1676769 >> Log: >> Fix another silly memory leak in JavaHL. >> This time, we forgot to close off a JNI frame. >> -

Re: svn commit: r1676769 - /subversion/trunk/subversion/bindings/javahl/native/CreateJ.cpp

2015-04-29 Thread Philip Martin
br...@apache.org writes: > Author: brane > Date: Wed Apr 29 15:30:54 2015 > New Revision: 1676769 > > URL: http://svn.apache.org/r1676769 > Log: > Fix another silly memory leak in JavaHL. > This time, we forgot to close off a JNI frame. > -m_env->CallObjectMethod(m_map, m_put_mid, jpropNa

Re: 1.9 JavaHL memory leak in ISVNRemote#status

2015-04-29 Thread Marc Strapetz
On 29.04.2015 17:44, Branko Čibej wrote: On 29.04.2015 17:03, Branko Čibej wrote: On 29.04.2015 16:02, Branko Čibej wrote: On 29.04.2015 11:57, Marc Strapetz wrote: On 29.04.2015 05:31, Branko Čibej wrote: On 28.04.2015 21:22, Bert Huijben wrote: -Original Message- From: Marc Strapet

Re: 1.9 JavaHL memory leak in ISVNRemote#status

2015-04-29 Thread Branko Čibej
On 29.04.2015 17:03, Branko Čibej wrote: > On 29.04.2015 16:02, Branko Čibej wrote: >> On 29.04.2015 11:57, Marc Strapetz wrote: >>> On 29.04.2015 05:31, Branko Čibej wrote: On 28.04.2015 21:22, Bert Huijben wrote: >> -Original Message- >> From: Marc Strapetz [mailto:marc.strap

Re: 1.9 JavaHL memory leak in ISVNRemote#status

2015-04-29 Thread Branko Čibej
On 29.04.2015 16:02, Branko Čibej wrote: > On 29.04.2015 11:57, Marc Strapetz wrote: >> On 29.04.2015 05:31, Branko Čibej wrote: >>> On 28.04.2015 21:22, Bert Huijben wrote: > -Original Message- > From: Marc Strapetz [mailto:marc.strap...@syntevo.com] > Sent: dinsdag 28 april 20

Re: 1.9 JavaHL memory leak in ISVNRemote#status

2015-04-29 Thread Branko Čibej
On 29.04.2015 11:57, Marc Strapetz wrote: > On 29.04.2015 05:31, Branko Čibej wrote: >> On 28.04.2015 21:22, Bert Huijben wrote: >>> -Original Message- From: Marc Strapetz [mailto:marc.strap...@syntevo.com] Sent: dinsdag 28 april 2015 20:26 To: Branko Čibej Cc: Subv

Re: 1.9 JavaHL memory leak in ISVNRemote#status

2015-04-29 Thread Marc Strapetz
On 29.04.2015 05:31, Branko Čibej wrote: On 28.04.2015 21:22, Bert Huijben wrote: -Original Message- From: Marc Strapetz [mailto:marc.strap...@syntevo.com] Sent: dinsdag 28 april 2015 20:26 To: Branko Čibej Cc: Subversion Development Subject: Re: 1.9 JavaHL memory leak in ISVNRemote#st

Re: Weird bug with directory deltification in 1.8.x

2015-04-29 Thread Roderich Schupp
On Wed, Apr 29, 2015 at 6:54 AM, Stefan Fuhrmann < stefan.fuhrm...@wandisco.com> wrote: > Fixed in r1676667. Details, regression test & backport tomorrow. > Thanks for the speedy fix. From the log message of r1676667 So, this fixes a data re-construction bug, not a repo corruption. > That's a g

RFC: Bump required Java version for JavaHL to 1.6

2015-04-29 Thread Branko Čibej
Subject says it all. Two reasons: * Java 5 has been officially dead since 2009 * 1.9 JavaHL uses Java6 APIs It's possible to cross-compile for Java5 using newer JDKs, but the compiler only checks language features, not library usage; for the latter, you actually need Java5 classes available.