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

Question

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 1

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.