RE: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Bert Huijben
Any idea what causes this difference? Is it all in the security walk? The diff --summarize should result in a single report from server to client, without additional get requests for data (except for the one time ra session setup, revision lookup, etc. at the start) Be

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Stefan Fuhrmann
On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > > > URL: http://svn.apache.org/r1648542 > > Log: > > In FSFS, remove the L1 DAG cache locking parameters. > > [...] > > As of this revision, I am also seeing random Apache HTTPD Server segfaults. > I tested two Sub

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Stefan Fuhrmann
On Tue, Dec 30, 2014 at 5:47 PM, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > > > URL: http://svn.apache.org/r1648542 > > Log: > > In FSFS, remove the L1 DAG cache locking parameters. > > [...] > > As of this revision, I am also seeing random Apache HTTPD Server segfaults. > I tested two Sub

Re: svn commit: r1648253 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Stefan Fuhrmann
On Tue, Dec 30, 2014 at 5:01 PM, Branko Čibej wrote: > On 30.12.2014 16:35, Ivan Zhakov wrote: > > Just to make things clear. The thorough review was already provided. > > In short, subpools are not a solution for the root cause of the > > problem being discussed. > The last bit is where we disa

Re: svn commit: r1648542 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Evgeny Kotkov
Stefan Fuhrmann writes: > URL: http://svn.apache.org/r1648542 > Log: > In FSFS, remove the L1 DAG cache locking parameters. [...] As of this revision, I am also seeing random Apache HTTPD Server segfaults. I tested two Subversion 1.9.0-dev builds from r1648532 and r1648542. I could not reprodu

Re: svn commit: r1648253 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Branko Čibej
On 30.12.2014 16:35, Ivan Zhakov wrote: > Just to make things clear. The thorough review was already provided. > In short, subpools are not a solution for the root cause of the > problem being discussed. It strikes me that the root problem is amazingly similar to the issue we had with pool lifeti

Re: ruby 2.2: check-swig-rb test fails

2014-12-30 Thread Anatol Pomozov
Hi On Mon, Dec 29, 2014 at 12:19 PM, Anatol Pomozov wrote: > Hi > > On Mon, Dec 29, 2014 at 5:19 AM, Anatol Pomozov > wrote: >> Hi >> >> I am trying to compile/run 1.8.11 svn tests with recently released ruby >> 2.2 and ruby swig test fails. See the output below. Looking at >> run-test.rb code I

Re: svn commit: r1648253 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Ivan Zhakov
On 30 December 2014 at 17:29, Stefan Fuhrmann wrote: > n Tue, Dec 30, 2014 at 2:03 PM, Ivan Zhakov wrote: >> >> On 29 December 2014 at 17:39, Stefan Fuhrmann >> wrote: >> > On Mon, Dec 29, 2014 at 1:46 PM, Evgeny Kotkov >> > >> > wrote: >> >> >> >> Stefan Fuhrmann writes: >> >> >> [...] >> >>

Re: svn commit: r1648253 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Stefan Fuhrmann
n Tue, Dec 30, 2014 at 2:03 PM, Ivan Zhakov wrote: > On 29 December 2014 at 17:39, Stefan Fuhrmann > wrote: > > On Mon, Dec 29, 2014 at 1:46 PM, Evgeny Kotkov < > evgeny.kot...@visualsvn.com> > > wrote: > >> > >> Stefan Fuhrmann writes: > >> > [...] > >> > >>libsvn_fs-1.dll!get_node_revisio

Re: svn commit: r1648253 - /subversion/trunk/subversion/libsvn_fs_fs/tree.c

2014-12-30 Thread Ivan Zhakov
On 29 December 2014 at 17:39, Stefan Fuhrmann wrote: > On Mon, Dec 29, 2014 at 1:46 PM, Evgeny Kotkov > wrote: >> >> Stefan Fuhrmann writes: >> [...] >> >>libsvn_fs-1.dll!get_node_revision_body() >>libsvn_fs-1.dll!svn_fs_fs__dag_get_node() >>libsvn_fs-1.dll!open_path() >>libsvn_f

Re: [RFC] Refining our naming rules

2014-12-30 Thread Greg Stein
On Mon, Dec 29, 2014 at 9:59 AM, Branko Čibej wrote: > On 29.12.2014 13:59, Stefan Fuhrmann wrote: > > Hi there, > > > > FSX code contains various violations to our naming rules, > > mostly taken over FSFS. I thought about a scheme that > > complies to our rules but also refines them. > > > > I'd