svn log crippled

[cm...@collab.net]

I just disabled (on the server side) 

   svn log -v
   svn log target ...

Because of the horrendous performance hit we suffer from undeltifying
directory entries lists, doing the path examinations with log for more
than, say, 30 revisions, is just a painful experience. 

Something we might consider as an alternative:  I'd be interested in
finding out how much performance we'd gain back if we stopped
deltifying directory entries lists in the filesystem.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn log crippled

[Karl Fogel <kf...@newton.ch.collab.net>]

cmpilato@collab.net writes:
> I just disabled (on the server side) 
> 
>    svn log -v
>    svn log target ...
> 
> Because of the horrendous performance hit we suffer from undeltifying
> directory entries lists, doing the path examinations with log for more
> than, say, 30 revisions, is just a painful experience. 
> 
> Something we might consider as an alternative:  I'd be interested in
> finding out how much performance we'd gain back if we stopped
> deltifying directory entries lists in the filesystem.

I was thinking about this too, since so many tasks just want the
entries lists and don't need the file contents.

At the very least, for both files and directories, we probably want
"checkpoint" fulltexts every N changes.  We could make N lower for
directories, even as low as 1.

First want some real numbers on dir sizes vs file sizes in the fs...

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org