Thursday, January 27, 2005
I have been on the lookout for a decent version control system for some time now. Yes, I realise there are loads out there, CVS and Ms VSS being the most prolific, however I had some pretty specific requirements. I work on projects that involve remote collaboration with team members, and we do not have luxuries like always-on servers that we can use to install a version control server on. Also, since we're doing commercial projects, and we don't want to give everyone else access to our code, we couldn't really go the source forge route (well, not the free one, anyway).
Well, we saw a (conceptual) solution to this problem: google. More specifically, google's gmail, in tandem with the brilliant gmailfs shell extension that allows windows users to use their gmail account as a remote file system. We figured that if we could find an entirely client-driven source control system that could make use of a local drive, we would be able to fool it into using gmail through gmailfs.
Well, it would appear we have found such a system. It is an open-source source control system called Subversion. Besides having all the functionality of CVS, it is really flexible in it's implementation. Historically it could only use a BerkleyDB database for it's repository, but an update in mid-2004 enabled the use of standard (remote or local) file systems. The repository does not specifically require any sort of server process to run, everything is controlled by lock files, making it totally client-centric.
In addition to the standard command-line driven interface, there are a number of third party clients available for the system, including a Visual Studio .Net plugin and a windows shell extension called TortoiseSVN.
Unfortunately I have not been able to get gmailfs to behave today (apparently google have made a change to the gmail API again..), so I have not been able to test Subversion on gmail, but as soon as it's up again I'll do that. Even if that does not work out, however, the nature of subversion means we should be able to zip up the repository and send it back and forth to achieve what we need to if push comes to shove..