more scalability problems

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:
 
      libsvn_wc/diff.c:581
      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
start.

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
   response?

---------------------------------------------------------------------
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