Ahh, I thought the timings were based on the envvar that Stefan suggested to try.  Thanks for clarifying.

On Tue, Nov 1, 2011 at 1:18 PM, <michael_rytting@agilent.com> wrote:

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:markphip@gmail.com]
Sent: Tuesday, November 01, 2011 11:18 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: stsp@elego.de; users@subversion.apache.org

Subject: Re: Apparent "svn rm" scaling problem in 1.7.x


On Tue, Nov 1, 2011 at 1:10 PM, <michael_rytting@agilent.com> wrote:

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 <file>  0.35s
svn st <file>    0.105s
svn blame  0.041s
svn unlock 0.056s
svn lock      0.053s
svn log   0.036s
svn info 0.014s


But look how much it improved compared to how much the others improved?  


svn rm <file>       7s
svn add <file>      0.126s
svn st <file>          2s
svn blame <file> 0.2s
svn lock <file>      0.12s
svn unlock <file> 0.103s
svn log <file>        0.089s
svn revert <file>  0.133s
svn info <file>      0.074s


Many of these commands are not even impacted by that variable.  That said, I do not get how this envvar can shave 7 seconds off the operation when it usually only sleeps for a second.



Mark Phippard


Mark Phippard