I've been bitten by the SVN bug lately; largely driven by heavy use of a personal repo at work for keeping control of proof-of-concept code, documents and small files, and for keeping my two machines in sync.

My home NAS, a D-Link DNS-323, is a solid little box with some extra scripts and packages installed to provide some daily backups--but it also has a few shortcomings that keep it from being used like I'd like to. My hopes were to use it as my always-on fileserver for home and remote use--but the permission controls are fairly weak and inflexible and access to it from outside my home network is limited to SSH/SCP and FTP (which is only turned on temporarily if ever).

So I thought to myself: what if I used it primarily as an SVN-based fileserver and allowed remote access via SSH+SVN. I could still have a non-SVN windows share for large files such as my laptop backups; but I could by-and-large use it as an SVN-repo for personal files.

The question here is where do I stop, what are the limitations on SVN regarding maximum repo size or size of files stored in it?

6 Answers 6


Joey Hess, a developer on the Debian project, has written a long, instructive article about using subversion for personal use: Subverting your homedir, or keeping your life in svn. I think you'll find some good ideas in there.

If you read carefully at the top and bottom of that article, you'll see that he first implemented this idea in CVS and now keeps most of his home directory in git


Subversion is mainly used as a source control system, therefore it's main intend is not to version binary files. What advantages do you see in using Subversion for keeping your System in Sync (i would find it terrible to always having to keep Subversion meta information in my normal files and managing that could become pretty annoying)?

Maybe a backup tool like rsync or the file Synchronizer Unison via FTP or SSH is more appropriate for what you want to do.


While subversion is for source control, I (ab)use it for backup. There are a number of interesting limitations I've run into:

  • using http transport, I have sometimes run into 2GB transfer limits on checkouts and commits, but not always
  • the .svn subdirectory has a second copy of every file, so you immediately double your space needs
  • large numbers of files in a directory get very slow
  • the subversion repository never shrinks; it will only grow in size, even when you "delete" a file because it keeps the history of that file having been there in the past

However, even with these limitations I find it works very well for me. One interesting thing you can do on the server is use the post-commit hook to push a copy of each commit to an offsite location automatically (using the svnadmin tool to do an incremental dump of that revision).

  • Oh, just remembered another one: when doing a checkout of my home directory to a brand new machine, I have to make sure I touch the mbox index files so that kmail doesn't rebuild them and throw out the read/replied/etc flags on it. Using maildir instead of mbox runs into the 3rd drawback that I already mentioned.
    – retracile
    Aug 13, 2009 at 16:34
  • Retracile, you can edit your answer to include your comment. On a related note, you can also delete your comment after incorporating it into the answer.
    – Travis
    Aug 19, 2009 at 18:47

As far as size limitations go, I've never had it reject a file. Including putting ISO files in there, etc. The repo size is almost always limited by the size of the hard drive, not by subversion.

In response to Daff's answer: rsync doesn't do what subversion can. Have an Ubuntu ISO you want to have available for burn everywhere you are? Great! rsync can distribute the file, it works great. But now you update to Ubuntu 69.88, but you find a week later it doesn't work on your old 486sx laptop. With rsync, you have to go hunt down an older ISO, download it, etc. With subversion, you can simply roll back to an older version of the file.

If you're going to use subversion for some files, you might as well go all out and use it for everything. The bigger files aren't as efficient, but might as well keep it centralized.

</2 cents>

  • You CAN do incremental, versioned backups with RSync and the main point was, that there are better suited tools for handling binary file Backups than a SOURCE Revision Control System (for backups I prefer it the other way around: let the server pull new backups instead of having to commit everything all the time). I never said that it doesn't work if you can live with all the drawbacks.
    – Daff
    Aug 18, 2009 at 12:41
  • backuppc.sourceforge.net shows how you can keep revisions of backups whilst using rsync.
    – gbjbaanb
    Jun 19, 2010 at 23:37

I've tried to make the push to using subversion for things other than my development code. I understand that while it works very nicely for users of designers because it has a historical account of the progression of the artwork. The book I bought for subversion starts with a mention that they do use subversion for everything including their grocery shopping lists. While I don't do much graphic arts, a mediawiki provides the same functionality in an already easy to use web based interface. It also has additional features such as a discussion about the content. I think Trac does very well by going the extra mile and incorporating a wiki with svn. Being new to svn, I haven't run into any limitation other than the extra time required for the additional steps.


Rock on! I've been doing this for a couple of years, and its really great! It does take a little care though, but now whenever I get a new machine I do svn co, and run a script in there and I get firefox and everything like I like it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .