Subversion's hidden revision files

Question

You know how Subversion stores a copy of every file it has checked-out in the hidden .svn folders? The website I'm building is pretty big (has over 1Gig of PDF files). These PDF files will very rarely change throughout the existence of the website.

I was wondering if there was a way of telling Subversion that it shouldn't store a local revision copy of a certain set of files (my PDF files) but just sync with the server whenever a change is made to any of these files?

Answer 1

You might want to consider managing the "live" copy of your website using svn export instead of a checkout. This would completely avoid the problem of large files in .svn folders.

Your workflow could be like this:

1. Edit files locally, test in test deployment
2. Commit changes to repository
3. Run a svn export from the repository to the live system

The disadvantage of this is that any changes that might have been made to the live system in the meantime will get overwritten. But you can arrange your workflow to avoid that.

Actually, it occurs to me that I don't know whether you are concerned about these hidden PDF files in your working checkout, or in the server deployment. If it's in your working checkout, then I don't know of a way to avoid these files using Subversion. However, if you use Git with git-svn, then Git will manage its own compressed history without full copies of all the files.

Answer 2

An idea in a different vein: if you use Bazaar+bzr-svn or Git+git-svn, they keep a much more space-efficient working copy and you can still update directly from your repository.

Answer 3

Subversion uses the version in the .svn folders to be able to diff the new file against the old file, and send just the differences to the subversion server.

So no, there's no way to not have the files inside the .svn folders, that still allows you to commit these files

Answer 4

As Greg says, use an SVN export -- but do the SVN export to a local directory, and then rsync that local directory to the remote site.

This gets you the combination of (a) not having the .svn directories and (b) only sending the changes from the local system to the remote.

Failing that, as both Greg and orip suggested, make the remote checkout using 'git-svn'. It still has some amount of overhead over the space consumed by an svn export, but it will be less than a full svn working copy.