Dropbox is one of my favourite services. It syncs files between multiple machines and the ‘cloud’, meaning that wherever you go you’ve got your files with you. It keeps a version history, lets you share folders or files, it’s free and rock solid.
If you haven’t already, check it out.
A programmer could probably get away with using Dropbox as-is for a very simple, single person version control system. But it lacks a lot of the common VCS functions, like check-in comments, branching and merging and advanced conflict resolution.
Putting Mercurial working directories on Dropbox compounds the benefits of both tools. Whenever you save a
document, it’s automatically versioned and sync’d via Dropbox – not just to the cloud but to any other running PCs logged into your Dropbox account. That means your hard dive can die at any time and you’ll lose almost no work, even if you haven’t checked in to Mercurial. It also gives you incremental file versioning, basically inter-checkin version control.
Usually with Mercurial you’d push your changes from one machine to a server, then pull those changes down to another PC. With Dropbox, your working directory, including non-checked in files, is available wherever you are.
Before work one morning you squeeze in some hacking time for an open source project. Lets say you’re writing a Rails app on your Linux box. Mid-idea you realise you really have to get going, so save everything and walk out the door, without committing to Mercurial.
In your lunch break you decide to do some more work on your project. You’re lucky enough to work somewhere that lets you install Dropbox. You open your Dropbox folder and all your changes from that morning are there. You hack the code into shape then ‘hg commit’.
Even though you’re using Windows at work, checking in to the Mercurial repo you created on your Linux box works just fine.
You do the hg pull/hg push dance with the master repo to share your changes with other project members.
There’s one major issue to be wary of. By keeping your Mercurial repo on Dropbox you’re version controlling your version control system files. If you somehow manage to cause a conflict with files in your .hg directory, things could get messy. Recoverable, but messy. For this to happen you’d have to do something like:
- work offline on your project, committing to hg
- before taking that offline machine back online, work on the same hg repo on another online machine, committing to hg
Then, when you take the offline machine online, Dropbox will attempt to merge the concurrent changes to the .hg files. Maybe it will work, maybe it won’t. This isn’t a show-stopper (I’ve never had it happen) and at worst you’ll lose some check-in comments and maybe have to merge some source files manually.
Also for this reason, don’t keep your your working directories in a shared Dropbox folder. That’s just asking for trouble.
Of course, you probably don’t want to start storing your work’s source on a cloud-sync’d system unless you have explicity permission to do so. Particularly if you’re working on closed source stuff.
If you’re using another VCS you should still be able to get a lot of advantages from keeping your working directory on Dropbox. For a central VCS like Subversion you shouldn’t even have to worry about the gotchyas, because all you have are a bunch of files not the repository itself.
The reason I think Mercurial is a particularly good match is because, like Dropbox it: is truely cross platform; is simple yet powerful; and generally, “just works”.