Re: Delta combiner stress test results

Branko Čibej <brane@xbc.nu> writes:
> * After each set of tests, I recursively compared the working copies
> (except the .svn directories). All the working copes were
> identical, _except_ that the trunk svn/branch repo combination
> corrupted files larget than 100k. I assume there's a latent bug in
> the undeltification code on /trunk that shows up when trying to
> undeltify files larger than the window size. We didn't notice it
> because there are no such files in our repositories. The branch
> sbuversion doesn't have this problem.

Heh. Nice discovery.

> The tests show that operations on the branch repo are slightly more
> expensive, because there's more undeltification going on. On the plus
> side, the branch repo is 30% smaller.

These time & mem differences are pretty small, insignificant really.

> Conclusion: The combiner is ready to be merged on the mainline. Please
> test the code in /branches/issue-531-dev on your repositories, and let
> me know the results. I'd be especially interested in results from
> really huge repositores, e.g., the Linux kernel archives I know some
> of you have created.

I'd be *most* interested in results for repositories versioning huge
files (~100MB), in two separate ways:

   - Huge file, but each revision is a small delta to it (like adding
        the string "fish" inside a giant image file)

   - Huge file, and each revision touches a lot of its bytes

Our showstopper scalability issue had been that we didn't deltify
files larger than the delta window size (~100k). Now that Brane's
fixed that, wouldn't be interesting to see where our limits are? :-)

> If everything goes well, I'll merge the combiner onto the trunk on Monday.

Bravo, sir!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 25 23:38:07 2002