I think it's a poor idea.

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.

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.

Using Dropbox for source control is like publishing an hour-by-hour activity log and claiming it's your autobiography:

  9 am: Typing. Still breathing.
  10am: Typing. Still breathing.
  11am: walking to lunch, breathing faster
  noon: eating.
  1pm: typing. Still breathing.

You want a system that tracks the deliberately edited, important points of the story. You also 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.

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..

I've been doing it with a small iphone project I've been working on with a friend. I can't say it's a good idea but it's better than nothing.