advice on setting up SVN

Question

I'm trying to setup an svn server.

I maintain couple of websites based on asp. There are three environments currently.

1. Development: Any new modules/enhancements will be done in this environment
2. Staging: Mirror of production
3. Production: The public facing website.

Currently when there's an update to the website, this is what we do

1. do the update in development
2. copy file to staging
3. copy file to production

In production we take a backup of the old file by renaming it.

I would like to make it simpler by installing SVN and stop the file renaming thing. But im not sure how many repositories to have per website. should be it be three or two? I'm absolutely new to svn. Just installed it in a linux based server (ubuntu). Can you pls advice how to go about it?

Thanks

-Vivek

Answer 1

My advices:
* Have one repository for each project. Each repository divided in trunk (main developing), branches (major changes releases folder) and tags(minimal changes releases folder) folders.
* If the project is not too much complex you can stack with the trunk only and maybe tags folders to get back track for older releases.
* Always develop in the trunk folder of each repository, unless you are coding 2 or more major changes for the same project, then develop over actual branch version and then merge all the stuff into trunk when finished.
* About renaming and such, use scripts about rsync daemon to synchronize the folders that contain the projects for your different stages, always in one direction: development -> testing -> production.

Answer 2

Here's an article that describes some best practices for using SVN for development:

http://www.sitepoint.com/blogs/2006/02/07/using-svn-for-web-development/

Answer 3

It's all in the book (including repositories examples). Chapter 5 is called Repository Administration, and there you'll find everything you need to know to decide how to set it up.

It's free (as in free beer and freedom) so there's no excuse, you really should read at least the first chapters in order to work with Subversion and have an idea of what you are doing.

Answer 4

Subversion is for maintaining a history of changes to your source code. It doesn't have any inherent "deployment" capability, which I think is what you are trying to accomplish.

That being said, you can organize your code using branches to maintain changes that haven't been deployed to stage or production environments, which will allow you to better keep track of those changes which haven't been deployed yet. You will have to set up your own deployer, which can pull the updated code out of these branches and push them to stage. When it is time to deploy to production, you can then merge the changes in the branch back into the trunk, and either tag or delete the branch, and start the process over again.

That's just one suggestion; there are many ways to configure a Subversion repository to accomplish what you are trying to do. You might want to read up on SVN a bit and then ask some more detailed questions. One source I can recommend is "Version Control with Subversion."