More recently I have started working with a team on a project, after a short time we realise we NEEDED to use some sort of versioning system, not only to avoid the possible lack of file locking, but also to allow us to quickly revert to a previous version when bugs/conflicts are found.

It took a short while to get the individual machines configured with necessary database servers and a dump of the test data to populate them.  After that setup, checkout the code and get to work.  A few short days later its easy to see the benefits, individual installations all testing new features being worked on, end of the day, commit (assuming everything works) then an update in the morning.  I get the benefit of seeing the new features, who has done them and get this stuff tested.

I decided to use it for myself, when I’m the only developer.  It doesn’t take long to see the benefits.

1. I work on the site locally, once I’m fully satisfied my local version is working, I commit.
2. Checkout the source code on a testing server, using a duplicate of the current live database to test.
3. A bit of backwards and forwards maybe.
4. Checkout the source code on the live server, your new code is deployed and ready to go with little to no downtime.

Although this sort of thing can be accomplished via FTP in a similar way, the process is not as slick, and in the event of a screw-up, checkout a previous working revision having minimum downtime.

As for SVN software for the client machines;

OS X users: Coda comes with SVN built in, this is my choice.

There is also a cross-platform client, both free & paid versions available. Smart SVN.  I also have this installed.

There are a lot of SVN clients, so it’s really a case of try and see.

Django 1.2 is now out, along with a bug-fix release for 1.1.  It looks like a bug has already been found, but that’s to be expected as the audience grows.  Better these problems are found early on.

Django 1.2 has a bunch of new features;