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 under

Answer 1

I've been using Dropbox with git for personal projects for quite some time now, and I haven't had a single problem yet. Although, there are times you have to wait for Dropbox to sync. I think this can cause minor problems if there are more than a few people working on the same project, but for personal projects, I find Dropbox to be even better than GitHub, if only for the fact that pushing/pulling is faster.

As for pushing/pulling mid-sync, this will most probably cause problems, and it might even corrupt your repo, but if you're the only one working on the project, then you know exactly when Dropbox will sync.

Answer 2

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.

Answer 3

For those who prefer to use Dropbox over bitbucket/github, here's what I do to avoid corruption from the 2-way sync process of cloud backup services:

My local code folder is c:\code & backup folder is c:\Dropbox. Inside the Dropbox folder, I have a truecrypt encrypted file container (It's size is sufficiently larger than my code folder). During the day I regularly commit changes to my local Git/Mercurial repository. However at the end of the day, I quit Dropbox & mount the truecrypt file container. I push changes to a bare repository in the file container, unmount it & re-start Dropbox.

That way, I can safely use a cloud service for serving as a backup of my DVCS repository. If the file container is in use, Dropbox will wait for it to be unmounted so hopefully, there's no change of corruption there. Still, if I get a conflicted copy of the file container somehow, I can easily mount both the copies and compare the changesets.

Answer 4

I'd expect problems if you try to access repository in the middle of the sync. It also seems to be a bit of overhead. You don't really need to sync over the stuff you sync. I have no idea how dropbox handles conflicts, but I doubt it can do it in an scm-aware way.

Answer 5

I suppose that would probably work okay for personal projects on one or two machines, but really you're going to want to use professional hosting for multi member projects.

I have personally used BitBucket for some time and have been quite pleased... you can have one private project on the free account, too.

Answer 6

I've had problems with my Dropbox'ed repositories becoming corrupted. It doesn't happen all the time, but the fact that it has happened more than once means that I'm going to stop using Dropbox for this purpose.

That said, Dropbox is certainly cheaper than getting real hosting, so as long as you keep backups you may find it acceptable for personal projects.