I'm genuinely curious: why do this, as opposed to using a DVCS like git?
I guess you could say Dropbox gives me finer sync granularity than git does.
Dropbox seems like a perfect solution: have a single place where you keep code, develop on two machines, just pick up your laptop and leave whenever you want, without worrying about sync.
Put it another way, I don't understand why you'd use Dropbox at all, after all you could easily version all your files in git, using push/pull/branch/commit/rebase to get your data to your different machines. Git handles this problem very well, after all.
Obviously with regular files, that is not an issue, so Dropbox works well. (unless you're managing them with git, I guess)
If you're willing to accept the "lightness" of git branching and commits, it's possible to "save and sync" your work very quickly. Assuming you're on a dev branch:
git add -A
git commit -m "temp commit 2013-7-3"
git push origin
You can even script this, see for example:
http://stackoverflow.com/questions/8482843/git-commit-bash-s...
Then when you're ready to work on a different machine, you fetch from origin.
If you want to keep your commits meaningful on your dev branch, you can create a temp branch first, then rebase later to get rid of the ugly temp commit.
git checkout -b temp123
Dropbox could help there, but it does not.
So I work on a directory that is in dropbox, and in git, and I can instantly shutdown my PC and start writing code on the laptop. Commiting changes is a separate step. It's quite convenient. Also I can test the code by accessing dropbox public link (it's mostly javascript and static websites), and there's no separate "deploy" step - when I save a file on any computer the change is ready to be tested, always at the same place. With git I would need to remember to commit, and update before I test, or I would need to set up a test server on every computer, and depending on where I work I would need to access different address. The difference between 15 seconds and 0 seconds to test small change is VERY significant.
The way people generally use source control isn't to push every single line added or changed to a remote copy of the repo as soon as it is done. A commit is more tied to completing a task, you need something else to cover you for loss for smaller amounts of code than that if your computer dies.
More specifically to me, it depends on what branch I'm on. If I'm on dev, I have no problem with big commits. (For features I'll often set a bookmark [hg]- maybe even clone and work from the clone if it's risky).
But if I'm on test or hotfixing on stable, I use very small commits so that I can easily graft (backport) back to dev.
But at the very least I have more than one commit message like -FIX blah blah commit so can get from <name of other machine>
That way the client can have programmers/designers change their UI without needing any access into the server. It also allows me to share each site and doesn't bring the entire headache of managing accounts. I simply share the yoursite.com folder to the client. If a client has multiple sites it's just as easy to share all of them.
Also, in many cases it is easier for a graphic designer or just a customer to put stuff in a Dropbox folder that will sync to their website, than uploading stuff using a web form or learning to use git and X amount of deployment tools.
... unless you're running on batteries.
I haven't used Dropbox in a while as a local client for other reasons but I think people need to appreciate this is the payoff for having the convenience? How can one expect it to sync changes if it never scans or detects changes? People seem to want a magical product where it never uses any HD throughput or CPU to index/scan/upload megabytes of data, sure it can look for changes less often but that decreases the usefulness of the product.
As a sidenote, surely all the dropboxers use dropbox for everything (they have unlimited accounts) so they must be 100% aware of this? in which case there must be concrete reasons for this!?
From my conversations with Dropbox support I understood that Dropbox really can't handle a large number of small files. The large plans are intended for people who store large files, not lots of stuff.
The indexation doesn't need to happen immediately upon boot. Do one directory every minute or so, let the computer start up and do other things while your background task runs.
Changes are detected because the operating system notifies dropbox of changes made, they're not continuously scanning the drive. From other comments it sounds like dropbox has registered a hook like that for the entire filesystem, instead of just the working folder. That seems unnecessary.
Why can't Dropbox remember the state of the files in your dropbox folder, and upon login, grab state of the files on the Dropbox server and do a simple comparison, without re-calculating hashes for the files on your computer?
I guess the methods I propose will not guarantee proper syncing if for some reason a file has changed but the metadata hasn't...
The new battery indicator on the menu bar identifies apps that consume the most energy, and Activity Monitor now details energy consumption per process.
First in list of features: https://developer.apple.com/osx/whats-new/
Last I tested, Dropbox consumed CPU for ANY changes ANYWHERE in your filesystem, not just within the Dropbox folder. So its (slow) code processed changes even when you untarred a large set of files somewhere in /tmp.
I also stopped using Dropbox for storing my code because of that — it's nearly useless, as it consumes so much CPU and eats so much battery life, that it simply isn't worth the effort.
Another problem with Dropbox is that upon login it indexes the entire Dropbox, which if you have an HDD basically kills the machine for several minutes, e.g. you can't do anything else. That happens to me on a Mac Pro. On an SSD-equipped MacBook things are better, but it's still a monstrous operation.
And to everyone that says you should not store code in dropbox: a) there are good and legitimate reasons for doing so, b) dropbox could work a little more on optimizing CPU usage instead of adding "save your photos to Dropbox" features.