Creating a subversion repository for website.

Question

What is the best practice for creating a website repository? Is the repository the live on the and does not require moving files from the repo? Or do you need to move files from the server repository to the web server?

Answer 1

1. 'import' your web root to the svn
2. delete your webroot
3. 'checkout' the svn to your webroot.

After this you can simply 'commit' while in the webroot to commit your changes.

http://aymanh.com/subversion-a-quick-tutorial

http://www.abbeyworkshop.com/howto/misc/svn01/

Answer 2

Never, ever work against live server files.

Always check into and out of source control from a local copy and prepare a deployment package for upload to your server.

Answer 3

Your web server can serve pages that come from a Subversion checkout, essentially using svn as a deployment tool.

First set up a Subversion repository as usual. Just the usual, common repository layout with trunk and tags at least. You might already have an existing repository. Do your development and check in your website code. Create a tag for the first version.

Then on the web server, check out a copy of the appropriate version. For example, cd /path/to/web/root/folder && svn co path_to_repository/tags/1.0 .

Let's say you update your site and check in the changes. When the update is ready to go live, once again create a tag for it. On the web server, switch to the new version by doing e.g. cd /path/to/web/root/folder && svn sw path_to_repository/tags/1.1

Note that this will of course litter your web root with .svn directories. This may or may not be a problem, depending on what you're deploying. For my sites, it's never a problem (I ensure they're protected via .htaccess).

The idea is that you do your development on development machines and only login to the web server after the new tag is ready and you're ready to switch the web server to the new version.

Answer 4

Randolpho is correct of course, you don't want to be working against the live server files.

You have a source control system, the purpose of this is so you can keep track of who changed what when and so you can change it back if you need to and know who to yell at for screwing it up.

You have the web server to serve your content.

And you have a deployment process which is the process of getting the content from source control installed on the web server. Ideally this is not a manual process. Ideally what you want to happen here is that when you want to deploy to the web server, you type a couple words on the command line and

1) The content is pulled from source control

2) It is verified that the content is all there and is going to do what you expect it to

3) The content is moved to the web server and anything that needs to be restarted is restarted

4) A test is done to make sure that the web server is up and that the content it is serving is the content you expect it to be serving.

Automation is a wonderful thing.