Convert Your Website to Subversion

23 Mar

.step{margin-top:0px;padding-top:0px;padding-bottom:3px;text-indent: -2em;padding-left: 1.9em;text-align:left}This guide is a simple step-by-step guide to help you convert your currently live website to a handy-dandy revision-control system called Subversion. It also contains information on how to create a discrete development environment where you can modify your site and test your changes without affecting live traffic.

If you:
…want a place to beta test your code
…want to keep a revision history of your code
…have every modified or deleted a file on your website and wished you hadn’t done that
…realize that CVS sucks cat ass
You should try subversion!

•You are hosted on a *nix machine*.
•You have SVN installed or can install it.
•You have SSH access to your site.
•Your web host allows for the creation of subdomains (if you want a dev environment).
•Your HTTP document root is not the root of your home directory. For example, when you log in to SSH, you see a list of system directories but one of them contains all of your web content.

•The command syntaxes that I provide are those used by FreeBSD. If you’re savvy on another system and you notice a syntax difference, please speak up.
•Throughout this text, I will refer to your web documents directory’s absolute path as docroot, the repository as repos, and your home path (the full path from the drive root to your home directory) as homepath.
•The paths described above do not contain trailing slashes. Do not add a trailing slash to paths unless specifically indicated.
•Always always always back up your data, especially before attempting something like this!
Subversion official documentation


You backed up, right?

1) First, start by running svn –version to verify you have Subversion installed. If not, you or your sysadmin should install it for you!

2) In your web root (~), create a directory named svn_import.

3) Within svn_import, create the following directories: trunk, branches, and tags. **

4) As a security precaution, add the following line to a file called .htaccess in your document root: RewriteRule (^|/).svn – [F]

5a) If you wish to add your entire site to revision control, use the command cp -R -p -v docroot/* ~/svn_import/trunk/ to copy your entire site into the import directory.
Note: The -p tag on the copy command is important, as some files on your site may have nonstandard permissions that you wish to preserve.

5b) If you only wish to add parts of your site, copy only those files and directories into ~/svn_import/trunk/

Creating and importing:

6) Create the repository: svnadmin create ~/.svnrepos

7) Import your site: svn import ~/svn_import file:///homepath/.svnrepos -m “Initial import”
Note: Yes, file:/// is correct. Make sure you’re using the full system path to your home directory for homepath

Creating your development area:
(optional, but highly recommended)

8) Using whatever means you use to manage your web site, create a subdomain for your web site called

9) HTTP password protect your new subdomain, so people don’t go poking around your work in progress. After all, you’re creating this dev area for a little privacy while you’re working.

10) Check out the repository into the beta site document root: svn checkout file:///homepath/.svnrepos/trunk dev_docroot
When this process completes, you should see the message At revision 1.

11) Look over your new dev subdomain. All of your pages *should* work on this new site, but if you hard-coded any full system paths, these ought to be changed to relative or dynamic.

Converting your live site to SVN

12) Create a temporary checkout directory: mkdir ~/svn_stage

13) Check out the repository to the temp dir: svn checkout file:///homepath/.svnrepos/trunk ~/svn_stage

14) If you got this far without backing up your site content, you should do so right now and then kick yourself in the ass for not paying attention to important instructions.

15) Move your repository onto your live content: mv ~/svn_stage/* docroot/
This previous step may seem odd, but the SVN repository you just moved onto the live site contains lots of .svn directories that are required to make your site act like a repository. It also helps ensure the shift doesn’t interrupt your site traffic, and if you opted for #5b, it doesn’t harm the files you didn’t want to add into SVN but still want to keep.

16) Test your fancy new revision control-enhanced web site!


17) Remove ~/svn_import

18) Remove ~/svn_stage

19) Edit the file ~/.subversion/config and uncomment the global-ignores line. You may wish to add space-delimited files that you want SVN to ignore. If you chose to follow step 5b, you should add the files and directories you didn’t want to import here.

•Now that your site is under this wonderful new revision control system, you can FTP all of your file changes into the dev_docroot path and test them on your dev subdomain. Whenever you make a change you want to store to SVN, you should commit your changes with the following command:
svn commit dev_docroot
•If you don’t provide during a commit using the -m flag, you will be prompted for notes about the commit. Add a brief description of the changes you made so you can revisit that version later on.
•Once you have checked in your fancy changes, you can check them out in your changes by running the following: svn update docroot
•Both your regular and beta document root are now repositories. This way, you can technically make and commit changes from either location. Whether or not you choose to do that is up to you, but the entire point of a dev area is that you don’t ever program in the live path again. It is my suggestion that you don’t directly modify SVN-controlled files in your live path.
•Now might be a good time to remind you to RTFM. This manual is well written and contains gobs of good information on how to use SVN.

If you’re used to CVS
First, congrats. You’re on the road to saner and happier revision control.
Next, you should read this.
Perhaps the biggest shift that you should know about is that revisions in SVN are commit-based, not file based. It is not accurate to say “file X is version 56.” You should say “file X was modified in version 43.” The key difference here is that any number of files and directories can be changed in any revision.

As an interesting aside to all of this, I like to keep a repository of every binary I download and install (applications and drivers). So I don’t have to keep the entire collection on my laptop or desktop, I have a media server that is also running SVN for Windows. My laptop and desktop use the SVN server to store all of the binaries I’ve downloaded. I can delete all but the most recent versions of the apps so they don’t appear on my other computers, but I’ll always have a backup copy of old versions within SVN.

* This document was written based on FreeBSD commands. If you are running RedHat or some other linux, the command flags may differ slightly. Refer to your help documentation to verify command flag differences.

**Click here for an explanation of the trunk, branches, and tags directories. If you don’t care about branching or tagging, you really don’t need to worry your little head about this.

18 Responses to “Convert Your Website to Subversion”

  1. Joshua Curtiss July 13, 2006 at 9:42 am #

    Thanks for the tips and instructions. I’m looking to use Subversion for revision control on my employer’s intranet (a few dozen apps) as well as a few personal websites. I’ve been wondering how to take the web architecture and fit it into Subversion in a clean and maintainable manner. Do you have any references for other articles that help with deploying web apps specifically, with Subversion?

    Thanks again..

  2. Sam August 4, 2006 at 2:13 pm #

    Great article!!!
    I’m having trouble when running the mv command to move from stage to my live site.

    mv: cannot overwrite directory `/home/sagreene/public_html/mydebtkiller/cgi-bin’

    Do you know what the problem is? I’m a little new with *NIX.

  3. Ian August 4, 2006 at 4:25 pm #


    The cgi-bin directory is most likely owned by a different user or is set with no read permissions. Frequently, such directories are owned by a special user so scripts within can be executed through the web server.

    If you don’t and don’t plan on using the CGI directory (few people do these days with the popularity of PHP and Ruby), don’t let it bother you. You can remove that entry from your SVN repository. You won’t get further warnings about it once your SVN setup is deployed.

  4. Sam September 6, 2006 at 9:19 pm #

    Just a syntax question, you use ~ to indicate webroot. In redhat, ‘~’ indicates the home directory. Should ~/svn_import be on the home directory or be within the docroot of the web, ie /home/usr/www/svn_import as opposed to /home/usr/svn_import?

  5. Sam September 6, 2006 at 11:03 pm #

    ^^ that guy again.

    I figured it out. Was just confused by the wording in step two, but you are using ~ in the same sense as other linux distros.

    Thanks for the tutorial, btw. The only one like it that I’ve seen.

  6. Michael October 29, 2006 at 10:49 pm #

    I have a cavaet on your .svn rewrite rule. The rule

    RewriteRule .svn [F]

    is more properly written (I think)

    RewriteRule .svn – [F]

    Also, this will block files matching *.svn*. In other words, it will block blah.svn and .svnblah as well as /.svn/blah. Granted, that’s not terribly likely, but it is possible. I’m currently looking for a solution because, on my host at least,

    RewriteRule /.svn/ – [F]

    doesn’t do anything. I haven’t figured out why yet, and so that’s how I came across your page. The weird thing is that

    RewriteRule /.whammo/ – [F]

    works. This may be because .whammo doesn’t exist, but I don’t know.

    Anyway, if I find an answer, I’ll post back here. And maybe by then I’ll have a blog running ;)


  7. Michael October 29, 2006 at 10:59 pm #

    Well, I found it…

    RewriteRule (^|/).svn(/|$) – [F]

    This seems to work for me. I’m not sure why…

    No, now I know. I was testing on, which would show up in the rewrite rule as ‘.svn’, which /.svn/ doesn’t match. Silly me ;)

    Incidentally, the solution was found at

    Now I’ll run along and play elsewhere ;)


  8. Ian October 30, 2006 at 12:15 am #


    Thank you for your comments. It appears that I’d forgotten two important characters: the backslash on the period and the dash before the [F]. I’ve updated the main post to reflect this.

  9. Michael October 30, 2006 at 6:03 pm #

    You’re welcome. I’ve since put this up at my web host’s wiki:

    Glad I could help.


  10. imparare April 14, 2007 at 11:14 pm #

    Interesting comments.. :D

  11. George June 11, 2007 at 6:37 am #

    Many thanks for a wonderful guide!

  12. Chapman June 16, 2007 at 2:28 am #

    Nice page greetings to all in this guestbook! Visit my sites, please:

  13. Will December 4, 2007 at 10:14 pm #

    If you don’t want do deal with the .svn files in the prod instance, just do an svn export instead.

  14. Au Pair March 20, 2008 at 8:13 am #

    very nice web site. My English is not so good, so I do not understandt it well, but it seems very good. Thanks

  15. Kalle May 6, 2008 at 7:29 am #

    Thank you for the guide, it works great.
    But now, I want to do same again with devArea and my local-Copy.
    Maybe youve got some hints for me? Is this possible? I’m wondering because of the svn Files, will they be versioned then, too?

    Thank you

  16. Bodvar July 26, 2011 at 3:15 pm #

    Thank you for your well written info. I have been working on this for several hours now on my website (through ssh), hosted with, and finally I have come so far as successfully checking out the repository to the “working directory” which I created in the backend as throun (for development). My backend by default creates two subdirectories: etc and www, and I checked the repository out to throun/www in order to be able to access it over the Internet with my browser. However, svn put it all within a subfolder .svnrepos (same as the name of the repository). How can I change this? Or am I misunderstanding something? (Most likely!)

  17. Bodvar July 26, 2011 at 3:40 pm #

    I found out how to check it out right, but maybe I have to wait a while until I can access the subdomain. The problem was that earlier the checkout had failed because the import did not finish. Checking out gave me nothing but problems until I imported the files again. But then I was getting confused by the path as set up on this page. :-(

    When I again did it to the letter, it all went OK.



  1. area chicago massage parlor - July 14, 2006


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 272 other followers

%d bloggers like this: