On 08.03.2012 02:13, Bert Huijben wrote:
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: donderdag 8 maart 2012 1:28
To: Stefan Fuhrmann
Cc: Subversion Development
Subject: Re: Revprop caching 'n stuff
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrot
Well let's just say it's not busted
due to insufficient permissions any more ;-).
I'll keep an eye on it as the week progresses.
>
> From: Greg Stein
>To: dev@subversion.apache.org; Joe Schaefer
>Sent: Wednesday, March 7, 2012 9:16 PM
>Subject: Re: svn commit:
On Wed, Mar 7, 2012 at 21:06, wrote:
> Author: joes
> Date: Thu Mar 8 02:06:56 2012
> New Revision: 1298258
>
> URL: http://svn.apache.org/viewvc?rev=1298258&view=rev
> Log:
> * svnpubsub/rc.d/svnwcsub* - need independent log dir due to new logrotation
> feature
Oh, right! Forgot about the rot
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 8 maart 2012 1:28
> To: Stefan Fuhrmann
> Cc: Subversion Development
> Subject: Re: Revprop caching 'n stuff
>
> On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
> > Hi all,
> And this
On 08.03.2012 01:28, Stefan Sperling wrote:
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
Hi all,
The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
> Hi all,
>
> The revprop caching I introduced in r1296604, -10
> plus -7211 (kudos to Daniel) has an issue when it
> comes to making long-lived fs_t detect revprop
> changes. OTOH, I think that it also provides a huge
> performance
Hi all,
The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it also provides a huge
performance boost when you use clients like TSVN
that fire a large number of "svn ls -v"-e
On Wednesday, March 07, 2012 02:07:24 am Julian Foad wrote:
> Daniel Shahaf wrote:
> > Thanks for the patch Alexey. Forwarding it to dev@.
> >
> > Alexey Neyman wrote:
> >> > > svn: Attempted to get textual contents of a *non*-file node
> >> > >
> >> > > The issue, as pointed out by email thr
On Thu, Mar 01, 2012 at 07:42:28PM +0100, Stefan Sperling wrote:
> Subversion-1.7.4 tarballs are now available for testing/signing by
> committers. To obtain them please check out a working copy from
> https://dist.apache.org/repos/dist/dev/subversion
> Please add your signatures to the .asc file
On Wed, Mar 7, 2012 at 8:23 AM, C. Michael Pilato wrote:
> On 03/06/2012 05:29 PM, Hyrum K Wright wrote:
>> After a bit of a bump today, I've added the use of the python logging
>> module to our test suite as a way of logging output from the test
>> framework and the tests themselves. The end goa
On 03/06/2012 05:29 PM, Hyrum K Wright wrote:
> After a bit of a bump today, I've added the use of the python logging
> module to our test suite as a way of logging output from the test
> framework and the tests themselves. The end goal is to remove all the
> many print() calls we have in the test
Philip Martin wrote:
>> Greg Stein writes:
>>> I'm talking about format. Specifically not following the basic
>>> rule of "one line summary. One blank line. Details." Julian's
>>> change is missing the blank lines, which many tools parse.
>>>
>>> That's what I don't understand. Are we expec
"Bert Huijben" writes:
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip
>> Martin
>> Sent: woensdag 7 maart 2012 13:42
>> To: Greg Stein
>> Cc: dev@subversion.apache.org
>> Subject: Re: svn commit: r1297921 -
>> /subversion/trunk/subversio
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip
> Martin
> Sent: woensdag 7 maart 2012 13:42
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1297921 -
> /subversion/trunk/subversion/tests/cmdline/svntest/sandbox
Philip Martin writes:
> Greg Stein writes:
>
>> Geez. Be smart, Philip. Obviously, that quoted content is dumb. I'm talking
>> about format. Specifically not following the basic rule of "one line
>> summary. One blank line. Details." Julian's change is missing the blank
>> lines, which many tool
Greg Stein writes:
> Geez. Be smart, Philip. Obviously, that quoted content is dumb. I'm talking
> about format. Specifically not following the basic rule of "one line
> summary. One blank line. Details." Julian's change is missing the blank
> lines, which many tools parse.
That's what I don't u
On Mar 7, 2012 7:11 AM, "Philip Martin" wrote:
>
> Greg Stein writes:
>
> > On Wed, Mar 7, 2012 at 05:27, wrote:
> >> Author: julianfoad
> >> Date: Wed Mar 7 10:27:15 2012
> >> New Revision: 1297921
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1297921&view=rev
> >> Log:
> >> Improve doc str
Greg Stein writes:
> On Wed, Mar 7, 2012 at 05:27, wrote:
>> Author: julianfoad
>> Date: Wed Mar 7 10:27:15 2012
>> New Revision: 1297921
>>
>> URL: http://svn.apache.org/viewvc?rev=1297921&view=rev
>> Log:
>> Improve doc strings of Sandbox.simple_*() test suite functions.
>
> If you're going
On Wed, Mar 7, 2012 at 05:27, wrote:
> Author: julianfoad
> Date: Wed Mar 7 10:27:15 2012
> New Revision: 1297921
>
> URL: http://svn.apache.org/viewvc?rev=1297921&view=rev
> Log:
> Improve doc strings of Sandbox.simple_*() test suite functions.
If you're going to switch from single-line docstr
Stefan Fuhrmann writes:
> On 06.03.2012 10:43, Philip Martin wrote:
>> Perhaps the read routines could be changed to always read the
>> revprop-gen file and refresh the cache if required. Obviously this
>> would involve more IO than the current caching strategy, but it would
>> still be more eff
Daniel Shahaf wrote:
> Thanks for the patch Alexey. Forwarding it to dev@.
>
> Alexey Neyman wrote:
>> > > svn: Attempted to get textual contents of a *non*-file node
>> > >
>> > > The issue, as pointed out by email thread [1], is that the
>> > > directory being merged contains a file with
On 06.03.2012 10:43, Philip Martin wrote:
Daniel Shahaf writes:
I believe you cannot assume svn_fs_t's will be short lived, and
_certainly_ cannot assume that the access pattern to an svn_fs_t
will be in any way related to random clients having random RA
sessions; for all the FS API knows, svn
22 matches
Mail list logo
