How good is Subversion at storing lots of binary files?

Question

I'm looking for a place to put a few GB of documents (mostly .doc and .xls). My team already has a Subversion server set up for managing the documents we create, so I'd prefer to use that if possible. How well will Subversion handle all this extra stuff? Most of it is legacy information and will only ever have one version, but it is possible that a few documents could be updated.

I've been warned that SVN isn't particularly lots-of-big-binary-files-friendly. I'm wary of trying it to see whether it works since they'll always be in the repository history even if I later delete them.

Any alternatives? We'll need the ability to comment on and/or tag documents, but we can use a Delicious-like service combined with the URLs for the documents in SVN (or similar).

Later I'm not so worried about diffs on the binaries since, as stated above, they won't change much. I'm OK with a slight hassle if they do -- it's no worse than SharePoint.

Answer 1

There's a difference between lots of big binary files, and a big number of binary files.

In my experience SVN is fine with individual binary files of several hundred megabytes. The only problems I've seen begin to occur with individual files of around a gigabyte or so. Operations fail for mysterious and unknown reasons, possibly SVN failing to handle network related problems.

I am not aware of any SVN problems related to the number of binary files, beyond their lack of merge-ability and the fact that binary files often can't be efficiently stored as deltas (SVN can use deltas).

So;

• 1000 1mb files = fine.
• 100 10mb files = fine
• 10 100mb files = fine
• 1 >1000mb file = not a good idea.

I would hope the size of your documents fits into one of the fine categories :)

PS - Thanks for the list formatting fix :)

Answer 2

Well it's going to take up alot of space storing all that in Subversion, I'll tell you that much. Subversion doesn't store binary files via delta's the way that it stores text files. It'll probably take up as much space as it would to just store a bunch of binary files on your hard drive, plus the repository.

You may be able to a server-side tiddlywiki to store the urls to the documents within Subversion.

If they are mostly .doc and .xls files, there's also Microsoft's Sharepoint.

Answer 3

It depends on how often the files are updated. It can't do anything about merging binary files and so everytime there's a conflict you'll have pain. Otherwise it's just storage and retrieval, and while it's not as good as with text it still handles that just fine.

Answer 4

I personally use Mercurial for such tasks. I've used it to store several hundreds of gigs of media. Yes, it takes up some disk space, but disk space is cheap. With Mercurial, you also get the benefit of it being distributed, so doing a "checkout", or clone as is know in Mercurial, you get the whole repo, not just a snapshot. If your server ever dies then, your still in business.

Answer 5

ditto what Dave said about Mercurial, but replace Mercurial with git.

Answer 6

From what I've seen Git is very fast compared to Subversion, and I've heard it's somewhat faster than Mercurial, but only by a bit. However, I've not specifically tested it with large, or lots of, binary files.

That being said the way Git tracks changes, I would imagine it's very efficient at dealing with binary files.

I can say this for sure though; Once I got used to Git there's no way I'd choose to go back to Subversion. When I have to work with Subversion repositories I still use Git though git-svn. This way I get all the advantages of distributed version control, but still have really nice support for pushing commits back to the central Subversion repository.

Answer 7

We built our subversion client exactly for this, as we did really big design/consulting jobs that really needed version control. We never had any problems with it.