You're never going to work directly in the Dropbox directory,
That is never really backed up, and doesn't make a lot of sense.
I've been doing this for a while - but using Dropbox as my working directory [1]. All he is doing here is using Dropbox as a backup - but such services exist (e.g. BitBucket) and are easier to sync to (one push and you don't have to wait for Dropbox to then sync).
Dropbox is useful for maintaining a consistent working directory between computers. I can hack around at work, go home to finish up and then commit. Brilliant :)
I've never noticed bandwidth/sync issues. Sometimes it takes a couple of minutes to get it's head round things; but not often (Dropbox really is great at "just working").
It also syncs over the local network which speeds things up no end when I work at home.
I don't compile any of these because they are python, php or ruby projects (I only write C at work :P). I do have a Ruby/Redis project that I run from the Dropbox folder for testing - that has never generated any problems to my knowledge.
It's not just backup because you can share directories across dropbox accounts, and dropbox maintains that central repo on as many machines as you want.
Last time I tried BitBucket it just didn't work over my employer's http proxy. Googled it and it was some unresolved issue back then, lots of people had the same problem.
This isn't bad, but why wouldn't you also host the live code on Dropbox as well. One of the biggest bonuses I see about Dropbox is the fact that I am, essentially, backed up all the time. If his computer blew up before he hit "push", he wouldn't have a copy. If my computer blows up, as long as I hit save, and Dropbox is synced, I'm good to go. If anything, I'd host my repo somewhere offsite that doesn't use Amazon S3, so that I'm extra backed up.
I usually save my working source file every small amount of time (quite often) and every single change would create a history version on Dropbox storage server which I don't need that much. I'm not sure how many versions are kept but it is totally a waste of bandwidth as well as storage. So, pick what & when a folder/file to be synced is one of the most key features that I'm waiting for. Yup, cause it's very useful for live projects in Dropbox folder.
Wouldn't the better solution be for Dropbox to cache those trivial updates to limit bandwidth? It's not as if code is the only thing that might have multiple small updates. Seems an optimization they'd want to solve for themselves, rather than relying on user behavior.
And if there's a limit to the version history, isn't the storage concern moot?
If you're pushing around a LOT of files(which I did for a game project's data, the asset compilation process involved several copies and processing) Dropbox can screw up occasionally. If it's just a few source files that you edit in place you're probably fine. Also, some apps may modify files(e.g. a local database) in place without touching their date, which is scary since Dropbox will never update the file until you manually touch it.
I am actually storing one of my hg repositories on Dropbox. I don't really see the advantage of having a separate "local" repo. either. I hope I'm not missing something...
And if I work offline on different computers now and then, pushing to the Dropbox which then merges the repos in a Dropboxey way? Are .hg directories safe for concurrent modification?
Interesting idea, but why not just use some disk space on a remote server that you pay for anyway? I use a VPS for this and use cron jobs for rolling S3 backups. (And, I need the VPS anyway.) If someone is not a developer, however, using Dropbox sounds like a good idea.
For those who can't afford a premium private repos, it's a good idea. You'd better off not symlinking the repo in Dropbox dir, or you'll keep dropbox very busy when you are editing files.
Interesting. I do something with SVN (and haven't had a problem so far). I have my Visual Studio project directory located in my Dropbox so the current file saves end up backed up.
I also have a local SVN server binaries and configuration stored in my dropbox, aswell as the svnroot. It means whatever computer I go to, I instantly have a local SVN server running too.
Naturally I don't have 2 computers running svnserv at the same time. It was the lower barrier to entry than SVK and the VS Git Extensions aren't quite there yet.
One thing that prevents me switching from SVN at the moment is that I like the fact that every time I commit I'm also performing a backup.
Is there anyway to set up hg to mirror all commits to another remote repository? Would that not be better than hoping your repository never goes over the Dropbox 2GB free limit?
Ah thats one of the gems I read today. Awesome, the same can be done for git I guess. I'm going to try it today.
P.S: I have a wicked-cool thought. A nice web interface to browse (shared-)git repos on Dropbox would be cool. I'm going to try writing one this weekend.
Yeah, git can work similarly too, though I can't remember the clone flag (--bare I think?). My dumb brain hurts whenever I try to do something moderately complex with git, so I tend to stick to hg.
I was a happy Dropbox user. Until I read that they only accept engineering resumes from grads of "top tier" universities. Sorry, but I can't entrust my data to a company with such fallacious and just plain stupid hiring practices.
That is never really backed up, and doesn't make a lot of sense.
I've been doing this for a while - but using Dropbox as my working directory [1]. All he is doing here is using Dropbox as a backup - but such services exist (e.g. BitBucket) and are easier to sync to (one push and you don't have to wait for Dropbox to then sync).
Dropbox is useful for maintaining a consistent working directory between computers. I can hack around at work, go home to finish up and then commit. Brilliant :)
1. http://www.errant.me.uk/blog/2010/04/a-nifty-way-to-manage-c...