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.****
>
> ** **
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/****
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/