Version control systems (VCS, or Revision Control Systems or Source Control Systems) are designed for software developers. They enable one or more people to work on source code, annotate changes, split and merge the code, link to bug tracking systems and a number of other things that are interesting to developers but not to most people!
Indeed then, for most people, you might expect that version control systems are not interesting at all. But you’d be wrong.
What makes them interesting to most people is the fact that most of us are very poor at looking after those all-important files that make up our business assets and often personal assets too. We copy, save and delete stuff without giving too much thought to what we are doing. Then later on we scratch our heads and wonder what happened to xyz piece of critical information. I wonder how many times you’ve gone through your emails to get a document back that you know should be (and may well be) on your hard drive somewhere. With desktop search systems now all the rage, you will probably find the document but then you realised that you used it as a template for another document and accidentally saved over the top! Or it got deleted when you were tidying up the old project folders …
Well, in step the version control systems to save the day. They will benefit anyone who recognise the above scenarios.
I’ve been using a VCS for over a year now for my day-do-day documents. I’m glad I did too as I used it to recover most of my documents after a drive failure earlier this year.
I started by using Subversion (SVN). This is a Centralised Versioning System. It requires a central server that is the hub and master for all documents and changes. It is very well supported and many low-cost web hosts also provide Subversion servers.
It is not ideal though for managing general documents. Firstly it does get quite slow (especially for larger files) and changes can only be committed over a live network connection so it’s no good for disconnected work. Secondly, I found it very sensitive to how it was used and I’ve often managed to get my repository in a mess that was very hard and very time consuming to recover from. This is not acceptable in a system that you have to rely on. I’m sure its fine for its original purpose of source control but it is not so good for managing day-to-day work.
Next I looked at Distributed Version Control Systems. The most popular of these (the free ones anyway) are: Git, Mercurial and Bazaar. Mercurial seemed to be the one best developed for Windows so I tried that. It does seem reasonable but it seems to balk quite a bit at large’ish files (a few Mb, it seems that the Windows interface at least hangs quite often at least on Windows 7) and that makes it unsuitable for our needs. Git seems to have a lot going for it but is not so well developed for Windows and is rather more complex, I haven’t tried it at least yet. So that leaves Bazaar. I’m now using Bazaar in anger and I’m quite impressed. It seems to handle large files sensibly, it is easy to set up (really easy), it doesn’t complain when you move files and folders round, it doesn’t get in the way, it’s reasonably fast. You can also use it with a central repository too like SVN.
Bazaar comes with integration to Windows Explorer but you will probably want to look at the command line options too for automation.
I’ve set up a schedule that runs a commit of my main repository “workdocs” every morning, noon and afternoon (9am, 12pm and 4:30pm) and the extra data that is kept in the repository is simply backed up as part of the regular backup since it is just a hidden folder in the root of the “workdocs” folder.
I then commit changes manually as and when I want to after making significant changes to files.
For really critical files, you could couple Bazaar with the file change detection of SyncBackSE to automatically commit changes or you could use AutoHotKey to intercept the <ctrl>-s key combination to run a commit before or after doing a save.