Slashdot Mirror
Performance Tuning Subversion
BlueVoodoo writes "Subversion is one of the few version control systems that can store binary files using a delta algorithm. In this article, senior developer David Bell explains why Subversion's performance suffers when handling binaries and suggests several ways to work around the problem."
first
Goatse!
Chilly urine!
Visual SourceSafe destroys all open sores garbage. Subversion is for amateurs.
claim that BSD is a and Juliet 40,000 website. Mr. de
My version control system is so fucking slow. It pisses me off to no end. I mean I'm all like trying to check stuff in and it takes forever. Thank god someone took the time to speed these bitches up.
Headline:
SVN Fixes an implementation flaw of CVS, worsens others, completely ignoring the big picture!
Have you considered the possibility that you're just retarded?
...but storing them in delta format is worthless. I've been a source control and build engineer for over a decade, and yes I store binaries in my repository. But only third-party binaries, like libraries. Generated files, such as libraries built from our source code, do not belong in source control. Store the source, generate the binaries.
Because disk space is nearly free, storing files in delta format no longer meets the original need, which was to decrease disk usage. But revision control systems were built on delta storage, which is actually a good thing in that syncing your workspace to the repository, or diffing revisions, is easy and quick because the system doesn't need to create the diff or send the entire file. Just send the diffs and apply them to the workspace. In short, a file's revision history is a history of the successive differences, so of course we want to store them as a diff chain.
But what about your compilers, linkers, and other tools? Store them in revision control? Third-party libraries change rarely enough that we all can afford both the disk space for full copies or successive revisions to be stored, and the time it takes to upload or download the entire package. Tools usually change less frequently. In both cases, I do not trust any revision control system to correctly patch my compiler or other binaries based on what it thinks the diffs are. If there's a bug in the system, how would you know? At least with plain-text files, a human can look at the differences and decide if they are correct.
And what about binary source files? You know, MS Office files, CHM files, and anything else which is not stored on disk in the same way it's presented in the authoring tool. If for example you store a Word DOC as successive diffs, but not everyone is using the exact same version of Word (on the exact same OS), or everyone is using the same version, but at some point in the file's lifetime that version changes, you're basically screwed. Use revision control for the benefits of centralized storage and labeling, but save yourself a migraine and always save full revisions.
And now, my recommendation to use Perforce: Not only is it a great product, but the technical support there is the best of any company I've ever dealt with, for any product in any industry, on any planet in any universe.... OK, you get the point. Time for more coffee.