On 8/28/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 8/28/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > I suspect the problem here isn't about working copy efficiency, it's
> > the fact that we delta-encode every file that gets stuffed into the
> > repository, even if it's something as simple as committing a file to a
> > local file:/// repository. That takes a lonnnnnnnng time on huge
> > binary files.
>
> That's why I was hoping Jeremy would hand some real world test cases
> off to DannyB so he could make it Go Real Fast ;-)
>
I've emailed every person who, on users@ has complained in the thread
about large file binary performance, and begged them to give me repos
and files i can reproduce with, promising to fix their speed issues.
I've even sent out the attached patch for testing
I'm still waiting for an answer. :-(
They seem to want solutions without having to test them.
The last time someone had a significant binary performance problem
with large files, I sent them the attached (which disables vdelta, and
as such, is only really a good idea on svndiff1 using repos and
networks with no 1.3 clients/servers).
Basically, tell anyone who wants to try that they should take this
patch and create a new repo with a patched subversion, and dump/load
the old repo into the new one, and give checkouts/etc a try.
The report from the one person who has ever tried it with large files
was that it sped up commit times from 45 minutes to less than 5 ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 28 15:48:43 2006