Geek Answers Handbook

Subversion Silent Files

Do you know how Subversion stores a copy of each file extracted in hidden .svn folders? The site I am creating is quite large (has more than 1Gig PDF files). These PDF files rarely change throughout the life of a website.

I was wondering if there is a way to tell Subversion that it should not store a local copy of the revision of a specific set of files (my PDF files), but just synchronize it with the server whenever any changes are made to the files?

+3
source share
4 answers

Subversion uses the version in the .svn folders to be able to distinguish the new file from the old file and send only the differences to the subversion server.

So no, there is no way to not have files inside the .svn folders that still allow you to commit these files.

+3
source

The idea is in another way: if you use Bazaar + bzr-svn or Git + git-svn, they save a much more economical working copy, and you can still update it directly from your repository.

+2
source

Perhaps you should consider managing a live copy of your site using svn export instead of checking. This would completely eliminate the problem with large files in .svn folders.

Your workflow might be like this:

  • Edit files locally, test in test deployment
  • Commit changes to repository
  • 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 will be overwritten in the meantime. But you can organize your workflow to avoid this.

Actually, it occurs to me that I don’t know if you are worried about these hidden PDF files in your work check or when deploying the server. If this is in your working check, then I don’t know how 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 files.

+1
source

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

This gives you a combination of (a) the lack of .svn directories and (b) only sending changes from the local system to the console.

If this is not the case, as suggested by Greg and Orip, do a remote check using 'git-svn'. It still has some overhead on the space spent on exporting svn, but it will be less than a full working copy of svn.

+1
source

More articles:


All Articles