I think it's a poor idea.<p>A set of backup snapshots is not the same as source control. Your source control history is a story you tell about your code. Each commit is an important event, encapsulated on its own, with a person to blame and a text description and a definite date. Whereas a history of file changes is just a history of file changes.<p>The other point to make is that there is only one timeline of file changes. That is far too one-dimensional for code development. You need the ability to branch.<p>Using Dropbox for source control is like publishing an hour-by-hour activity log and claiming it's your autobiography:<p><pre><code> 9 am: Typing. Still breathing.
10am: Typing. Still breathing.
11am: walking to lunch, breathing faster
noon: eating.
1pm: typing. Still breathing.
</code></pre>
You want a system that tracks the deliberately edited, important points of the story. You <i>also</i> want backups, of course, but they don't accomplish the same thing.
Mercurial, Git, Fossil, etc. are all extremely easy to setup. I'd setup one of those and then setup a branch/clone in DropBox. Mercurial and Git have hooks that can run when a commit is finished. Just write a quick hook that automatically keeps the branch/clone in sync with your changes.
Dropbox solve one part of the source control equation. It doesn't handle conflicts nor annotations well at all.<p>It may be adequate protection from code loss, but does it enable you to work in a team?
I have been using Dropbox for over 3-4 months now. Initially we used it with mercurial. But later on we moved to fossil as it's a more natural fit. It's perfect for small teams and it's cheap..