Ubiquitous version control

The more I use it the more applications I find for version control, and each time I find a new application it alters the way I work.

In the first instance, version control is just a safe place to store your code and keep track of changes between revisions.

If you use a concurrent versioning system such as svn then it also becomes a tool for collaborative working. Two people can work on the same file and each time one of them commits their work to the repository the other can automatically incorporate the changes in their copy of the file.

I've started using the same functionality to manage staging and live versions of websites. The web server connects to svn just like any other user and can update its copy of the site to the latest version with a single update command. Bye bye ftp.

I sometimes work from home and it's very useful to be able to pick up the exact code that I've been working on at the office. Martin Fowler takes this even further in MultipleDesktops. In my latest project I've set up the repository with not just the code, but also the specification documents, the HTML pages I need to get started and my own notes and documentation.

One problem I have with using version control for remote working is that I don't want to commit broken code. Then I watched this screencast on Atomic Coding (BTW aren't screencasts great). It's very much in the spirit of agile and test driven development, and is made easier by using dynamic languages without a compilation cycle. The trick is to make small steps, where each step produces working code of some description. When the time between commits is no more than a couple of hours there's not much opportunity to leave code where I can't get at it remotely. Another benefit of atomic coding is that commits act as a kind of bookmark so I can keep track of where I am when I'm switching between several projects, which is often the case when your working on web site timescales.

I don't think I'll have hard time adapting to the atomic approach. The biggest change will be at the start of a project where I usually write a lot of code before running anything. To code atomically I'll have to make sure each class runs before I move on to the next one.