What are the consequences of the big changes to Subversion?

Question

I recently made a large set of changes (~ 7,000 files) in my svn repository. These 7000 files make up only 5% of the total repository size, which uses the FSFS backend and is serviced using svnserve 1.7. Since then, extracts with revisions after this mega-fix take more than 20 times.

What does Subversion do inside that causes a slowdown, and is there a way to fix this?

Update

• When manually checking a bad revision, I see the point at which the reverse check begins. The launch begins with the quick addition of files to the working copy (you cannot read the tty output quickly). Once a scan reaches a specific directory (a bad revision adds 2,000 files to this directory (which contains 17,000 files)), the files are added to the working copy much slower (for example, 5 files per second) for the rest of the scan. A review just before a bad one adds files to a working copy very quickly all the time. Files in this directory are approximately 1 KB.

• I compiled my own version of svnserve for versions 1.6 and 1.7 --w-debuging and --with-gprof so that we can get an idea of ​​what is going on. Some further testimonies show that some improvements made in svnadmin 1.7 related to in-memory caching actually kill it during this revision. Ie serving the repository with svnserve 1.6 fixes this problem . I assume that in-memory caching was discussed at http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning based on gprof profiles for validation time with poor revision (and one right in front of it ) In rBAD, some svn fsfs cache functions are called about 2,000,000,000 times more than in rGOOD.

Answer 1

Yes, many performance improvements have been deployed with the release of SVN v1.7. But based on some general assumptions. For extreme cases, such as a huge number of files in a single commit or files with a huge size, you will need to configure predefined parameters, as indicated in the relase notes.