Source code kept in SVN repository - what do I need to back up?

Question

I have recently been tasked with implementing version control on our development systems. I created an SVN repository using TortoiseSVN by doing the following:

• Installing the SVN server on the machine storing the code
• Using the repository browser on that machine to import the source code into the repository

Having imported the code, am I right in thinking that there is no longer any need for the code that was stored there? No commits from working copies on other machines seemed to have changed that code, only the svn repository.

I am familiar with the concept that the SVN does not store the raw code simply, but rather the differences. For that reason, my question is: is backing up the SVN repository folder ON IT'S OWN sufficient as a backup strategy for this code?

We do also do a manual backup of the code on the working machine every month as a precaution, and I am considering writing a scheduled batch file to svndump the repository to remote drive daily. If I do the latter, and we, hypothetically, lost both the repository server and the working machine, would we be able to recover the code from this daly svndump?

Hope that makes sense; Thanks in advance.

Answer 1

Backing Up the SVN repository server should be sufficient. One thing to remember is if the working machine goes down you would lose any configurations you have made to the working machine such as server configurations, system variables etc, so make sure those are documented. If you are running in a virtualized environment you can take a backup of the machine image, which would really speed up your recovery time.

As for svndump, That is exactly what it is used for. You can create a new repository and load the dump file and you will have your working code and everything you need.

I would suggest doing a dry run of a recovery using the dump file, that way you will be confident you are creating the dump file correctly and you won't be trying to figure out how to restore the dump file when an actual emergency is occurring.

Answer 2

After you have imported your code into the repository, that original "source" should be removed. It's not linked to the repository (unless you performed an in-place import) and you don't want people coming across it to think that they can/should keep using it. Now that your stuff is in SVN, that repository is the canonical source for your code.

Making a simple copy (or backup using your enterprise backup tool of choice) of the repository database folder as your backup may not be sufficient. If your copy is performed while another operation is in progress, you may end up with a backup of the repository in an odd state. This isn't as large of a risk today as it was when BDB-based repositories roamed the earth, but it needs to be a consideration.

Use svndump or svnadmin hotcopy to make your copy for backups instead. For more details, see the manual.

You will still need to back up your access control configuration (unless you're using the new-in-1.8 feature of storing it in the repository itself) and your hook scripts. Those are not handled by svndump or svnadmin hotcopy.

Bear in mind that if you're performing a daily backup and there's a lot of churn in your repository, you are still very exposed. If you take backups at midnight and the hard drive has a head collision at 11 PM, you've lost the whole day's work. For this reason, some repository administrators make an incremental dump or hotcopy more frequently during the day or for the truly paranoid, after every commit.

Backing up working copies on developer workstations (or your "working machine") is not useful if you need to restore your repository, as those working copies do not hold repository history. Do it if it makes you feel better, but working copies are considered disposable in Subversion. The only reason to do this is to back up changes that people haven't committed yet (in which case, why are they holding back?), or to speed up the process of getting back to work after that backup is needed (by not forcing them to perform a new checkout).