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

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_at_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_at_gmail.com]
> *Sent:* Tuesday, November 01, 2011 11:18 AM
> *To:* RYTTING,MICHAEL (A-ColSprings,ex1)
> *Cc:* stsp_at_elego.de; users_at_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_at_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/