Re: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-06 Thread Ben Reser
On 1/5/14, 3:13 AM, Branko Čibej wrote: > That raises the question: why is it not a common feature request here on this > list? And what's wrong with telling users to use the RA API instead of writing > myriad wrappers for it? The only "hard" part of that is creating the RA > session, and we alread

Re: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-05 Thread Branko Čibej
st have found > the fsfs symptoms months from now when releasing 1.9) That's irrelevant (on this list). I won't say a word about what the above statement implies for your QA workflow. :) -- Brane > -Original Message- > From: "Branko Čibej" > Sent: ‎05/‎01/

RE: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-05 Thread Bert Huijben
SharpSvn we would just have found the fsfs symptoms months from now when releasing 1.9) Bert -Original Message- From: "Branko Čibej" Sent: ‎05/‎01/‎2014 04:51 To: "Subversion Development" Subject: Re: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc

Re: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Branko Čibej
On 05.01.2014 01:53, Stefan Fuhrmann wrote: > Hi Bert, > > All your arguments would be valid and I would fully agree > with them, if the FS layer was the root cause of the pool > issue. However, IMO, that is not the case and r1555297 > merely accidentally caused free memory to be reused > earlier t

Re: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Stefan Fuhrmann
d pool handling by destroying the mtcc with its > parent pool instead of partly destroying it in some API function. > > -- Stefan^2. > > -- >> From: stef...@apache.org >> Sent: 4-1-2014 15:05 >> To: comm...@subversion.apache.org >>

Re: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Bert Huijben
t: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c Author: stefan2 Date: Sat Jan 4 14:04:36 2014 New Revision: 1555350 URL: http://svn.apache.org/r1555350 Log: Fix segfault in svnmucc. * subversion/libsvn_client/mtcc.c (svn_client_mtcc_commit): We explicitly destroy the

RE: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Bert Huijben
quot;Stefan Fuhrmann" Sent: ‎4-‎1-‎2014 22:26 To: "Bert Huijben" Cc: "dev@subversion.apache.org" ; "comm...@subversion.apache.org" Subject: Re: svn commit: r1555350-/subversion/trunk/subversion/libsvn_client/mtcc.c On Sat, Jan 4, 2014 at 9:47 PM, Bert Huijben

Re: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Stefan Fuhrmann
pool instead of partly destroying it in some API function. -- Stefan^2. -- > From: stef...@apache.org > Sent: 4-1-2014 15:05 > To: comm...@subversion.apache.org > Subject: svn commit: r1555350 > -/subversion/trunk/subversion/libsvn_client/mtcc.c >

RE: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_client/mtcc.c

2014-01-04 Thread Bert Huijben
especially generated bindings (like swig) have strange pool handling much longer. Bert -Original Message- From: "stef...@apache.org" Sent: ‎4-‎1-‎2014 15:05 To: "comm...@subversion.apache.org" Subject: svn commit: r1555350 -/subversion/trunk/subversion/libsvn_c