Mercurial (and, I guess Git) with Dropbox: any drawbacks?

daphshez picture daphshez · Dec 26, 2009 · Viewed 9.8k times · Source

I have a Mercurial repository for a personal project, and I have been storing the master repository in my Dropbox for a few weeks now (something along this line; and I understand it's also possible with git).

The idea is that it serves both as a way to work with multiple machines and as a remote backup. I clone the repository and work on the non-Dropbox copy, and only push updates once in a while, the same way I would, I suppose, work with Bitbucket.

Can you think of any drawbacks to this idea, compared to using dedicating hosting (BitBucket in the case of Mercurial)? I know Bitbucket has free accounts for single users, which is great, but they are limited to 150M, which isn't a huge.

In particular, is it possible that Dropbox's sync process would corrupt the repository? I had to run hg recover once on the master repository, but it might be unrelated (and anyway it happily recovered). Does anyone have a bad experience with the idea? Does anyone have a longer good experience and can alleviate my worries? Does anyone have an opinion based on better understanding of the internals of these things?

edit: I added some clarifications to the questions. They are in italics.

Answer

Ry4an Brase picture Ry4an Brase · Dec 27, 2009

I'd advise against it for the reasons stated above, but more strenuously stated. Both mercurial and git have their own protocols for moving changesets between repositories. These protocols are optimized/built for:

  • efficiency
  • consistency (never can you pull from a repo in a half-updated state)
  • hooks/triggers -- doing things on push/pull including quality (no tabs allowed, etc.) filters

When you just let a directory sync handle the keeping of the .hg (or .git) directories in sync then during that sync you've got a remote store that's in an inconsistent state and doesn't know it.

Additionally both hg and git have a separation of what's local-only and what's remote-okay within their disk state. They know what info to share (example: commited changesets) and what not to (example: current, local working directory parent revision).

In other answers folks are saying "you'll probably be fine" or "I've never had a problem" and that's likely true, but it's not guaranteed true, and revision control isn't a place to play the odds. Use the proper, better, safer, more efficient, more full featured synchronization protocol for your source control system.