Subversion: setting up a remote repository and running my site off it?

Question

Hi all.

I'm new to SVN and have experimented with it locally on my Dreamhost test server (which has a Subversion "one-click-install" function).

Having found my way around the functionality I'm definitely sold, but a little lost about using it to manage my work website (not hosted with Dreamhost, so not offering a one-click SVN installation).

Am I correct in thinking that I can set up a repository on my website root (which contains all the files), and then when I develop new features and run a commit, this will update my site? Is this the proper workflow for this sort of thing?

If so, is there a standard way to set this kind of thing up on my remote server?

Thanks.

Answer 1

If I understand your question correctly, you're trying to use subversion as an intermediary between your local development environment and your production environment. You wish to develop your website in a separate location, commit your changes, and then have those changes propagate to your production website. If that's not correct, please reply.

Something like this is certainly do-able. To get the terminology correct, in subversion you have a "repository" that lives on your subversion server. You never ever touch the repository itself, except indirectly by performing operations using an svn client. You can "check out" multiple "working copies" of the repository (or a sub-set thereof) to access your source files themselves. To achieve what you're asking, you would create a working copy on your development machine and make your changes there. When satisfied, you "commit" them to your repository. On your production location, you would have to create another working copy of the same repository location. You need to explicitly run "svn update" in this working copy to have the latest changes applied to it. Changes do not automatically propagate to all working copies on a commit.

If you haven't yet, you should take the time to read through the subversion book. It is an extremely valuable resource for subversion and the principles of source control in general.

Answer 2

To automate the updating of the website root, look into using a post-commit hook.

Post-Commit Hooks run after a changeset has been successfully committed to the SVN repository. Therefore, you could perhaps have your post-commit hook trigger an SVN UPDATE on the website root.

Answer 3

Both of the previous answers are good information. But there are a couple of issues that I thought a good idea to present. Should you go with the post-commit-hook idea I would suggest that the script to be made smart enough to only do the deploy when you specifically wish it too. To have the script do a deploy on every commit would be very restrictive and force you to forego many of the advantages of using source control.

One idea would be a keyword trigger in the comment that the script could use to trigger a deploy to production. Another would be to deploy only when the script determines that the commit is to a new tag folder.

Setting up the prodcution system as a local working copy and using SVN UPDATE does not have the problem of deploying commits that might not be ready for deployment to production, but suffers from not being as automatic. To solve that issue you could create a script the runs periodically on the production system that examines the repository in much the same way that a continous integration system like Crusie Control or Team City does and periodically examine the repository for a new commit and then do the update.

In either case I would suggest that you build the script smart enough to only deploy from a new TAG folder. That way you can use source control for all of the advantages that it brings and only deploy when you create a new TAG folder.