Coming from a compiled C++ background, I've always used revision control software to track changes to source code. Arriving at UQ I assumed that I could set up a subversion server and do the same for web application development. But there are some significant differences when working with svn on websites and here are some of the things I've learned.

* HTML and PHP files can be easily stored in subversion but how do you track changes to your database schema? A way around this is to use a migrations scheme similar to Ruby on Rails which can store your DB changes in a SQL script which can be put under revision control. It requires a lot of discipline but means that in a small team, others can do an svn update and then run the a 'db upgrade' script to get the latest database schema and even changes to default config data. Obviously you have to be a bit careful as it's not simple to do a rollback of your database so it is still suboptimal. * File permissions on webservers are often important. It's useful to have a script that you can run after a svn update or checkout to make sure that files are correctly writable by the webserver when they need to be (It's also good to reduce the need for this in the first place). If the script is under version control then new server writable files can be added to it as needed. * Using subversion to rollout a live site helps you track exactly which version of the site is running. We use a seperate branch in subversion for the live site as it often has a few little customisations that aren't in the main development branch. We can tag in subversion each time we do a rollout. * On a live server, different users might need to update parts of the site at various times but the svn client wants to always set the .svn/entries file to be read only and owned buy the current user. This is a bit annoying especially if you don't want you svn users to have a root ssh account or ability to change owenership of other users files on the server. One way to get around this is to have a 'svnuser' that people can login as to do the updates on the live site. However when commiting from the live site, the real username of the perpetrator is then lost (or you can restrict the svnuser on the live site to svn updates only). So there is extra complexity at this point making use of subversion that little bit hard. * Which brings me to my last point which is that subversion has a learning curve for new web developers coming to the team - they need to be trained on how subversion is used in your organisation and get used to the habits of remembering to commit schema changes and comment commits appropriately etc... If your programmers have never come across revision control before, at least subversion has an excellent online book which walks through all the concepts. * WebSVN has proven to be a helpful addon as we can subscribe to the commit messages via RSS and keep in touch with what's going on. It can also link in with our ticket system if we reference a ticket number in the commit message which in turn puts a link to the WebSVN commit record in the ticket.

Even though we only have a small development team, subversion has allowed us to work in parallel on things, using our own staging areas and databases and still share our progress. We still have to think about how things are going to play for the other programmers when we do a commit but most of the time, the benefits of the RCS far outweigh the overheads of spending extra time to write commit messages, writing schema upgrade scripts and mucking about with subversion's quirky permissions.