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
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/
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
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
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 than before.
My understanding of mucc_commit is the follo
In the case of svnmucc the passed scratch pool is a subpool of the pool that
the Ra session id created it (where the mtcc is created in). This is a
perfectly valid case of using pools, just like the common iterpool pattern.
If this shows a bug in the caching of the fs layer we should fix that b
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
On Sat, Jan 4, 2014 at 9:47 PM, Bert Huijben wrote:
> You only know this for the success path. The fs api should hide these
> details..
>
With all due respect, the fault is svn_client_mtcc_commit
destroying mtcc->pool before destroying mtcc itself (via
its owning pool). Hence, the caller has no
You only know this for the success path. The fs api should hide these details..
There is no way we can document these guarantees for public APIs and really
assume that all existing and future users follow all these new requirements for
a new Fs layer cache.
We had similar caches in the past, bu
9 matches
Mail list logo
