Ok, to wrap this up for now: r1102471 finally put these thoughts into
notes/diff-optimizations.txt, with some of Stefan2's feedback/ideas
integrated into it.
I also added another, previously mentioned idea into the notes file,
which I forgot to mention in this mailthread:
--- 8< ---
Avoid some ha
Fortunately shell scripts aren't really white-space sensitive, so I've
just pasted it inline.
> Just a reminder, you always have the option to use svnsync + 'svnadmin dump'
> instead of 'svnrdump dump'.
The more serious of the two bugs are on the svnrdump *load* side;
svnsync doesn't help with th
Mark Eichin wrote on Thu, May 12, 2011 at 16:26:56 -0400:
> I haven't looked at the actual code (at this point I may be out of
> time and have to go with convincing people that git-svn's
> approximation is good enough)
Just a reminder, you always have the option to use svnsync + 'svnadmin dump'
in
Mark Eichin wrote on Thu, May 12, 2011 at 16:26:56 -0400:
> I found what appear to be three distinct bugs, demonstrated by the
> attached script.
It didn't reach the list... could you try again with a different MIME type?
I'm working on some svn migration-with-history between repos from
different companies, git-svn isn't cutting it (close, but it loses
properties entirely, and doesn't really give me enough control) so I
thought I'd give svnrdump a try, given that it's been recommended for
this use a bunch of times..
C. Michael Pilato wrote on Thu, May 12, 2011 at 15:10:12 -0400:
> On 05/12/2011 03:08 PM, danie...@apache.org wrote:
> > Author: danielsh
> > Date: Thu May 12 19:08:08 2011
> > New Revision: 1102426
> >
> > URL: http://svn.apache.org/viewvc?rev=1102426&view=rev
> > Log:
> > Fix a bug introduced in
On Thu, May 12, 2011 at 11:49 AM, Mark Phippard wrote:
> For Neon, I think it is significant. In my case, 1.7 Neon issued 6,308
> fewer HTTP requests. My latency is .2 seconds. So that lopped around
> 21 minutes off the total test time when comparing Neon to Neon. I
> realize with Serf it is le
On 05/12/2011 03:08 PM, danie...@apache.org wrote:
> Author: danielsh
> Date: Thu May 12 19:08:08 2011
> New Revision: 1102426
>
> URL: http://svn.apache.org/viewvc?rev=1102426&view=rev
> Log:
> Fix a bug introduced in r2149647.
You sure about that?
--
C. Mich
On Thu, May 12, 2011 at 2:37 PM, Justin Erenkrantz
wrote:
> Hmm. More specifics on your configuration would be helpful if I am to
> try to reproduce your setup. Serf version? (0.7.2 or higher would be
> needed to avoid the Nagle issue.) OS (client & server)?
Serf trunk @ HEAD
Client is Wind
On Thu, May 12, 2011 at 11:02 AM, Mark Phippard wrote:
> On Thu, May 12, 2011 at 1:57 PM, Justin Erenkrantz
> wrote:
>>> Wasn't the patch for mod_deflate? And just to fix the memory leak
>>> when a client that does not support gzip connects?
>>
>> Are you by chance using SSL?
>
> No.
Hmm. More
On Thu, May 12, 2011 at 1:57 PM, Justin Erenkrantz
wrote:
>> Wasn't the patch for mod_deflate? And just to fix the memory leak
>> when a client that does not support gzip connects?
>
> Are you by chance using SSL?
No.
> I'm seeing something like a 2x perf drop on ra_serf with SSL to an SSL
> se
On Thu, May 12, 2011 at 7:34 AM, Mark Phippard wrote:
> On Thu, May 12, 2011 at 10:31 AM, Justin Erenkrantz
> wrote:
>> On Thu, May 12, 2011 at 7:23 AM, Mark Phippard wrote:
>>> I re-ran the results with your latest changes and posted the new numbers.
>>
>> Is that with the commit as well as the
Hi All,
Attached patch fixes the File descriptor leaks in ra_serf's way of
driving the destination delta editor with *LONG* living pools.
This patch fixes it.
I think similar stuff needs to be done for a case of directory having
lots of subdirectories.
All tests pass over ra_serf... I am
Daniel Shahaf wrote on Sun, May 08, 2011 at 19:27:06 +0300:
> rhuij...@apache.org wrote on Sun, May 08, 2011 at 13:20:08 -:
> > +svn_prop_array_to_hash(const apr_array_header_t *properties,
>
> How does it handle an svn_prop_t with a NULL 'value' member?
r1102367
On Thu, May 12, 2011 at 7:34 AM, Mark Phippard wrote:
> On Thu, May 12, 2011 at 10:31 AM, Justin Erenkrantz
> wrote:
>> On Thu, May 12, 2011 at 7:23 AM, Mark Phippard wrote:
>>> I re-ran the results with your latest changes and posted the new numbers.
>>
>> Is that with the commit as well as the
> -Original Message-
> From: phi...@apache.org [mailto:phi...@apache.org]
> Sent: donderdag 12 mei 2011 16:18
> To: comm...@subversion.apache.org
> Subject: svn commit: r1102321 -
> /subversion/trunk/subversion/libsvn_wc/entries.c
>
> Author: philip
> Date: Thu May 12 14:17:32 2011
> New
On Thu, May 12, 2011 at 10:31 AM, Justin Erenkrantz
wrote:
> On Thu, May 12, 2011 at 7:23 AM, Mark Phippard wrote:
>> I re-ran the results with your latest changes and posted the new numbers.
>
> Is that with the commit as well as the patch I posted (but did not commit)?
Just the commit.
Wasn't
On Thu, May 12, 2011 at 7:23 AM, Mark Phippard wrote:
> I re-ran the results with your latest changes and posted the new numbers.
Is that with the commit as well as the patch I posted (but did not commit)?
Thanks! -- justin
On Thu, May 12, 2011 at 2:12 AM, Justin Erenkrantz
wrote:
> On Wed, May 11, 2011 at 4:40 PM, Mark Phippard wrote:
>> The story using Serf is not as good. There are a few places where it
>> is fastest, namely merge. But there are other cases where it is
>> dramatically slower. The number of HTT
I noticed recently that the behavior when working with externals have
changed in SVN 1.7. Local changes to the svn:externals property in the
working copy is by default not honored during an update, before a commit.
...
> If you do
> Assuming you committed
> $ svn propset svn:externa
On Fri, 2011-05-06 at 21:47 -0400, C. Michael Pilato wrote:
> On 05/06/2011 07:08 PM, Greg Stein wrote:
> > On Fri, May 6, 2011 at 17:06, Hyrum K Wright wrote:
> >> On Fri, May 6, 2011 at 4:01 PM, C. Michael Pilato
> >> wrote:
> >>> Is there a convention in HTTP user-agent strings to use whitesp
[ adding dev@httpd ]
On Thu, May 12, 2011 at 12:25 AM, Ivan Zhakov wrote:
> On Thu, May 12, 2011 at 11:18, Justin Erenkrantz
> wrote:
>> On Thu, May 12, 2011 at 12:16 AM, Ivan Zhakov wrote:
>>> Unfortunately huge memory leak in mod_deflate/mod_dav prevents
>>> enabling gzip on compression on p
Daniel Shahaf wrote:
> julianf...@apache.org wrote on Wed, May 11, 2011 at 20:11:52 -:
> > Code simplification.
> >
> > * /home/julianfoad/src/subversion-d/subversion/libsvn_ra_serf/commit.c
>
> Wrong path, also in some other commits today.
Thanks for telling me! I fixed this and three othe
On Thu, May 12, 2011 at 1:09 AM, Justin Erenkrantz
wrote:
> This patch will also halve the amount of data that ra_serf retrieves
> for the basic benchmark test (28MB down to 13MB on the wire)...but,
FWIW, ra_neon sends:
Accept-Encoding: gzip
Accept-Encoding: svndiff1;q=0.9,svndiff;q=0.8
Accept-E
On Wed, May 11, 2011 at 11:12 PM, Justin Erenkrantz
wrote:
> r1102173 will help slightly when there are lots of checkouts as
This patch will also halve the amount of data that ra_serf retrieves
for the basic benchmark test (28MB down to 13MB on the wire)...but,
what's rather odd is that the svndi
On Thu, May 12, 2011 at 12:25 AM, Ivan Zhakov wrote:
> It would be great! Since I'm not familiar with this part of codebase
> and cannot fix it myself.
The quick-and-dirty fix is to set the no-gzip environment variable
within the filter before mod_deflate disconnects itself.
Re-architecting the
On Thu, May 12, 2011 at 11:18, Justin Erenkrantz wrote:
> On Thu, May 12, 2011 at 12:16 AM, Ivan Zhakov wrote:
>> Unfortunately huge memory leak in mod_deflate/mod_dav prevents
>> enabling gzip on compression on production servers, especially on
>> Windows where single process mode is used:
>> ht
On Thu, May 12, 2011 at 12:16 AM, Ivan Zhakov wrote:
> Unfortunately huge memory leak in mod_deflate/mod_dav prevents
> enabling gzip on compression on production servers, especially on
> Windows where single process mode is used:
> http://svn.haxx.se/dev/archive-2009-08/0274.shtml
*shrug*
Sound
On Thu, May 12, 2011 at 10:12, Justin Erenkrantz wrote:
> On Wed, May 11, 2011 at 4:40 PM, Mark Phippard wrote:
>> The story using Serf is not as good. There are a few places where it
>> is fastest, namely merge. But there are other cases where it is
>> dramatically slower. The number of HTTP
29 matches
Mail list logo
