In addition to slow "svn rm" commands we are seeing some pretty severe
slowdowns for "svn ci" as well. For example, here is an interesting situation.
I want to checkin a single file in my repository. If I run "svn ci" from the
root of my working copy it takes 1m11s to complete. However if I
Benchmarking with 49 files is taking too long. Here are some benchmarks of
trying to delete a directory with 5 files. I am using approximations because I
am seeing variations in each run due to network traffic.
"svn rm dir/*" 1.6.17 ~0.15s
"svn rm dir" 1.7.1~10s
"svn rm dir/*"
I'd have to do some research to get the options. It's a proprietary filesystem.
That being said, I understand that nfs mounted working copies will degrade my
performance. I really think this is a more fundamental performance issue with
svn rm that gets exacerbated with slow performance over nf
It's just one directory that has 49 files in it.
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Tuesday, November 01, 2011 11:22 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Apparent "svn rm" scaling problem in 1.7.x
On Tu
Perhaps I wasn't clear, the second set of runs where with a local working copy
instead of an nfs mounted working copy.
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Tuesday, November 01, 2011 11:18 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: s...@elego.de; users@subversion.apache.org
Su
Oh and to measure the time, I'm using a stopwatch and synchronizing the start
of the command with pressing go on my stop watch. I then push stop when the
command completes.
P.S. Actually I'm using the linux time command :) i.e. "time svn st "
-Original Message-
From: Stefan Sperling
LOL! I love the env variable.
Here is some similar data for a local working copy. These are all run with the
env variable set. Again, svn rm is significantly slower than all other
operations.
svn rm 0.35s
svn st 0.105s
svn blame 0.041s
svn unlock 0.056s
svn lock 0.053s
svn log
Not much of an improvement. "svn rm dir/*" now takes 2m6s vs 7s for "svn rm
dir".
As a side note, I really think there is fundamentally something wrong of the
performance of "svn rm" with large working copies. Here are some example times.
svn rm7s
svn add 0.126s
svn st
I'm always willing to try patches.
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Tuesday, November 01, 2011 2:49 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Apparent "svn rm" scaling problem in 1.7.x
On Mon, Oct 31, 2011
I did an additional benchmark doing "svn rm dir/*" on a local directory instead
of an nfs directory. It runs in 10.4s. Is going from 10.4s to 6m15s
acceptable when using a working copy on nfs vs local? I am fine with a certain
amount of slowdown when using nfs. But, I don't see this kind of
I am starting to see some very bad performance with "svn rm" compared to the
1.6.x line of subversion. I have a directory that is full of files. If I go
into the directory and run "svn rm *", it is significantly slower than running
svn rm on the whole directory. While the difference in time t
Very well, we'll move it to users. I just figured it was a bug in 1.7 since
the performance of the svn info -depth infinity was SIGNIFICANTLY faster in
1.6.x. Currently it takes 1 minute with 1.7 and less than a second with 1.6.x.
-Mike
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Thursda
I did. It didn't help.
-Mike
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Monday, August 22, 2011 10:48 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.mar...@wandisco.com; d...@subversion.apache.org;
users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4
No luck, still crashing.
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markp...@gmail.com; d...@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling
No luck with that option, still crashing.
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: Wednesday, August 10, 2011 4:20 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markp...@gmail.com; d...@subversion.apache.org; users@subversion.apache.org
Subject: Re:
> > I'm using gcc. The default in the makefile.
>
> I think RHEL may have come with two different gcc, a 3 series and a 4 series.
> What version does 'gcc -v' show?
3.4.6
> It would be good to confirm that at runtime you really are using the version
> of libapr you compiled, run ldd on the
I tried running -O2 and -O1, both were crashing as well. Only completely
disabling optimizations will cause the segfault to stop.
-Original Message-
From: David Chapman [mailto:dcchap...@acm.org]
Sent: Wednesday, August 10, 2011 5:39 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.
It is set to 1
On Aug 10, 2011, at 3:51 PM, "Philip Martin" wrote:
> writes:
>
>> I am attaching a stack trace with symbols enabled.
>
> Thanks!
>
>> I'm using gcc. The default in the makefile.
>
> I think RHEL may have come with two different gcc, a 3 series and a 4
> series. What versio
I am attaching a stack trace with symbols enabled.
I'm using gcc. The default in the makefile.
I am using the apr that you get from the get-deps.sh script. APR_HAS_THREADS is
defined.
If I disable optimizations by doing "make CFLAGS=-O0" the program no longer
crashes.
-Original Message--
And of course I forget to actually attach the file.
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On T
I am attaching a patch file which I used to change utf.c in the head revision
to get things to play nice with el4 64bit. "make check" does come back clean
with this version.
-Mike
P.S. why isn't "make check" structured so that the -j option to make would
work. It would be nice to use multipl
Ok, I've tracked down which revision caused the problem. It happened in rev
1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. Ever
since this change went in I am seeing subversion crash when I compile on 64bit
el4.
Just for kicks and giggles I updated to the HEAD revision
Unfortunately, some of us don't have a choice what version of linux we have to
run on. I end up compiling almost all the dependencies for subversion myself.
I guess I'll need to track down exactly what change in the development process
started breaking things. For now, we have a solution wher
Like I've said, I was able to build subversion 1.7.0 on our 64bit systems in
the past. The build flow hasn't changed. I've put a lot of time into trying
different options to the build flow and I'm pretty sure that isn't the culprit.
As for your second recommendation, it doesn't look like libma
For a while I was downloading and running the development build of subversion
1.7.0. At one revision of the code I started having an issue where svn would
immediately segfault. At that time I stopped using 1.7.0 assuming the issue
would be fixed before release. Unfortunately I just downloaded
25 matches
Mail list logo
