[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

more scalability problems

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-10-24 02:11:53 CEST

Well, last week our community managed to clean up a whole bunch of
memory leakage discovered when working on large trees (42,000 files).

This week, I've been testing svn against large files: I've created a
directory with 10 files, of sizes {1 meg, 2 meg, 4 meg, .... 512 meg}.

Here are my results:

* import: all good. client and server stay < 5M
* checkout: all good. same result as import.
* Add 5 bytes to 256M file. 'svn status' returns instantly.
  But 'svn diff' grows client to 56M, then segfaults here:
      a call to svn_err_compose() where err2 is NULL (!)
* Run 'svn commit' on modified working copy:
     sends txdelta for 8 minutes... client and server each around 5M
     then finally:
      svn: MERGE request failed on '/svn/bigrepos'
      subversion/libsvn_ra_dav/util.c:274: (apr_err=175002)
      svn: MERGE of '/svn/bigrepos': timed out waiting
                                     for server (http://localhost)

So that's at least three new bugs discovered:

1) why is 'svn diff' brute-forcing diffing the 256M file, rather than
noticing *up front* that it's a mime-type binary, and thus
unprintable? It should return an 'unprintable diff' error at the

2) we need to fix that silly segfault. I think that error-handling
   code in diff.c is bogus.

3) why the heck are we getting MERGE response timeout? Is the
   repository trying to deltify the previous version before sending a

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 24 02:14:38 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.