How to benefit from SVN in web development

I am managing the development of currently two different web applications of which one will roll out in beta testing before sunday.

I have some previous experience from SVN usage, after playing around a few hours with TortoiseSVN locally on a XP machine, but I never really got the hang out of it to be honest.

However, it feels like it's about time to rethinking SVN and really try to give it an honest chance. I would at least sleep alot better if I know that versioned backups of each file wer开发者_如何转开发e available and it was easy to roll back changes to an web applications whenever something hits the fan. Especially as the app grows bigger.

I currently work exclusively with PHP in Eclipse and deploy all files for the beta environment through FTP.

I have read most posts here about using Eclipse with SVN plugins, but I really doesn't understand how the workflow practically would look when SVN is used.

Do I check in every morning to my repository, do what i do best, and at the days end commit all changes?

How would sync be kept between local file structure, SVN repository, and multiple environments (live env., testing env., etc)?

Tell me about how your workflow looks when using SVN!

You may want to start by going through the free online book:

• Version Control with Subversion published by O'Reilly Media

Chapters 1 and 2 go through the fundamental concepts and the basic usage of Subversion. Then the remaining chapters explore more advanced topics.

Here's my steps with SVN for what I do:

1. Branch to work on bug/feature -> When starting to work on a bug or feature, I create a new branch taking the head revision of the code so that I'm in my own sandbox of sorts.

2. When I've fixed the bug or finished the feature, then comes the switch back to the main branch and merging in the fix so that it becomes part of the next code push into either dev clean or test. While this isn't exactly simple, it isn't as painful as one may fear.

Periodically, there are other things to do:

1. Clean up old branches -> As features and bugs get done, sometimes it is worth going back and pruning the work done so that the folder doesn't become huge in the Repo-browser.

2. Update code on my box -> Sometimes I'll go a little time between features and bugs, though I'd still like to keep the code on my machine up to date as much as possible.

Hmm,

If I may mention the little app I'm working on currently, dashy: http://www.mirios.com.au/dashy, it handles what you're concerned about from the deployment/configuration side (rolling back changes, handling configuration of multiple environments: dev/staging/live, etc) and is suitable for Windows + SVN only, at the moment. (Getting started with it, however, will be slightly involved, and the documentation isn't particularly complete, though it gives an idea).

As to how to use SVN in general, well, you have a build server, and you use a CI system to to automated builds, then you commit to your CI server (We use CruiseControl.NET, Hudson could do it as well). Further to this, you generally update in the morning, to check if anyone in the team made relevant changes, and use branches and tags where appropriate.

It's kind of complicated, (but not really) and once you get started and get everything installed, life should be quite good (whether or not you use dashy).