As a PHP coder and web developer, I have recently discovered and fallen in love with a tool which helps to keep my source code safely backed up. This tool is called Subversion and “it is used to maintain current and historical versions of files such as source code, web pages, and documentation.” (1) In simple terms, it allows you to back up your files and keeps a history of all the versions of files that you send to it.

This is VERY useful when doing PHP development because as you develop your application you can commit versions of the files to the Subversion (SVN) repository and it will keep track of all the changes you have made. If necessary, you can even revert back to older versions.

One of the difficulties that I have run into while doing website development is how to keep the live remote website synchronized with my local working copy. This is especially true of WordPress installations where editors may be uploading new pictures or documents to the site on a daily basis. If you are not constantly downloading the latest copy of the website, your local copy will be out-of-date and may cause problems in your development.

Subversion to the Rescue:

However, I have come up with a relatively simple solution to this problem, which utilizes the controls within Subversion, to both back up the data on the LIVE website, as well as providing version control for all the site data as a whole. For the sake of simplicity, I will be using a WordPress website as my example, but the concepts here could be applied to essentially any website.

One of the useful features of Subversion is the ability to run what they refer to as “hook scripts” at different points in the versioning process. For example, an SVN repository can be configured to run a set of scripts directly after any data is “committed” to it. (sending data to the repository is called “committing” the data) For this example, this is exactly the functionality we are going to be using.

Before I go any further though, let’s go over some of the requirements for setting up a website and subversion repository in this way.

WARNING: The following tutorial could seriously damage/destroy your website and/or server if you don’t know what you’re doing. We take no responsibility for any problems which may occur from following these instructions.

We HIGHLY recommend that you not employ these ideas on a LIVE webserver until you have thoroughly tested things in a development environment and fully understand how things work. Proceed at your own risk. You have been warned!


  1. You will need shell access to the server.
  2. The subversion repository must be on the same server as the website, and you will need to be able to run subversion commands on the server.
  3. The user which runs the subversion repository, must also have access to add and remove files from the live website.


Subversion Repository (SVN): The subversion repository which will contain all the website data. Needs to be located on the same server as the website and have access to the website’s files.

Local Working Copy (LWC): Term used to refer to the Working Copy of the SVN repository stored on your personal computer.

Remote Working Copy (RWC): You will need to be able to set up a remote working copy of the SVN repository on the same server as the website and SVN.

Setting it Up:

The first step in setting up a website to use SVN in this way, is to set up the SVN repository itself. I will not go into detail on how to set up an SVN repository, but for the sake of the article, let’s assume we can create the SVN repository at the path “/svnRepository/” on the remote server. We will create the subversion repository by typing the following on the remote server shell.

svnadmin create /svnRepository

The next important piece of the puzzle we need is the Remote Working Copy. Let’s assume that we can store the RWC at the path “/remoteWorkingCopy/” on the remote server. To do this, we will enter the following shell command:

svn checkout file:///svnRepository/ /remoteWorkingCopy/

Finally, we will make the assumption that you already have a website set up on the remote server, and it is located at the path “/www/”.

In order to set this up properly you will need to ensure that you can connect to the SVN repository. Though I will not go into the details of how to use Subversion here in this article, you need to be able to check out a copy of the remote SVN repository to your local machine.

Synchronizing the Website with SVN:

The next step in this process is to synchronize the current website with the SVN repository. To do this, we will be working on the server and will need to copy all the files from the website into the Remote Working Copy. To do this you would enter the following commands on the remote shell:

cp -r /www/* /remoteWorkingCopy/

cp -r /www/.ht* /remoteWorkingCopy/

These two commands should copy all files from the website over to the RWC. Now, unfortunately, the RWC doesn’t yet know what to do with these files, so we have to instruct it that all the files should be added to the SVN repository. We would do this with the following command:

svn stat /remoteWorkingCopy/ | grep ^? | sed s/^?// | xargs -r -i svn add “{}”

As indicated above, this command should prepare all files you have just copied to the RWC to be committed to the SVN repository. The final step is to run the actual “commit” command, and you would do that as so:

svn commit -m “Website Backup” /remoteWorkingCopy/

This command will go through the RWC and send all the new files you just added to the SVN repository where they are versioned and backed up.

Set Up Automatic Website Updates on POST-COMMIT:

We now have copy of the website stored in the SVN repository, as well as in the Remote Working Copy, but unless we take further steps, these filesystems will very shortly be out-of-date with the LIVE website. We also don’t yet have a way to get changes that we make to the SVN files back onto the website.

In order to do this we will need to set up a POST-COMMIT hook script. This is a script in the SVN repository which runs after every time a commit is called. In order to install the script, simply place it in your /svnRepository/hooks/ folder and make it writable. The script is as follows:



# Website BasePath

# Repository Path

# Remote Working copy


# Update the current working copy
echo “Updating the working copy ” $LOCALWC
svn update $LOCALWC

# Propogate deletes, adds and modifies from the SVN repository to the website.
echo “Doing Deletes!”
svn log -qvr $REV $LOCALWC | grep “^ D” | sed “s/^ D //” | sed -r “s# \(.+\)##” | xargs -r -i rm -rf $BASEPATH{}

echo “Doing Adds!”
svn log -qvr $REV $LOCALWC | grep “^ A” | sed “s/^ A //” | sed -r “s# \(.+\)##” | xargs -r -i svn export –force $LOCALWC{} $BASEPATH{}

echo “Doing Mods!”
svn log -qvr $REV $LOCALWC | grep “^ M” | sed “s/^ M //” | sed -r “s# \(.+\)##” | xargs -r -i svn export –force $LOCALWC{} $BASEPATH{}

# Copy current website files to current working copy
echo “Copying current website files to working copy”

# Automatically add all added and changed files from the website to the SVN repository.
echo “Adding and changing files”
svn stat $LOCALWC | grep ^? | sed s/^?// | xargs -r -i svn add “{}”

# Commit changes from working copy to SVN Repository
echo “Running commit”
svn commit -m “Website Backup” $LOCALWC

When you put this script in your /svnRepository/hooks folder and make it executable, the script will be run every time you commit something to the repository. Here is an outline of what it does:

Steps in Detail on Commit:

  1. User runs UPDATE on their local machine to get latest info from repository
  2. COMMIT is called
  3. UPDATE the remote working copy.
  4. Check svn log for deleted files in the Remote Working Copy and remove them from the website.
  5. Check svn log for added files and export them to the website.
  6. Check svn log for modified files and export them to the website.
  7. Copy all live website files to Remote Working Copy.
  8. Add all new files to be versioned in the RWC.
  9. Commit all additions and changes from the RWC to the SVN repository.
  10. The next time the user runs an update, it would get the latest files from the repository which should be synced to the website.


The end result of this process is that when changes are made on your local machine and committed to the SVN repository, the script will run, it will synchronize the website with the RWC and then will deploy your changes TO the website.

I hope you have found this tutorial useful. As mentioned above, be very careful as you work through the process of running these scripts and commands, as you could potentially cause major breakdowns on your website. Again, we take NO RESPONSIBILITY for any problems which may result from following this tutorial. Follow these instructions at your own risk.

I would love to hear any feedback you may have about this article. I would also like to hear from developers who may have more experience with this topic than I do and would be willing to make suggestions for improvement.


  1. Subversion (software) – From Wikipedia, the free encyclopedia

Related Reading:

Fantasy: The Literature of Subversion (New Accents)Fantasy: The Literature of Subversion (New Accents)This study argues against vague interpretations of fantasy as mere escapism and seeks to define it as a distinct kind of narrative. A general theoreti... Read More >
Practical Programming for Strength TrainingPractical Programming for Strength Training

There is a difference between Exercise and Training. Exercise is physical activity for its own sake, a workout done for the effect it produces toda... Read More >

WordPress security + multi-backups : My automated 4-destination strategyWordPress security + multi-backups : My automated 4-destination strategyWordPress is one of the most popular platforms for websites, with or without blogs. WordPress is getting better all the time. But thanks to its popula... Read More >
Filed in: PHP Programming, PHP Scripts, Webmaster Tools, WordPress Related

One Response to “Website Subversion Backup”

  1. Carson Says:

    The idea of having subversion backup is cool, but I would not do this on a live webserver. I’d rather create a backup of a whole site using a website backup service or just FTP everything over using scheduled backup.