Dropbox is not a suitable replacement for something like Subversion or Git for controlling changes to source code. There is some functionality to revert to old versions of files, but (to the best of my knowledge and consulting with the documentation) there is no support for performing merging, or branching. There are some APIs that expose diffs, but you would need to find a way to integrate these APIs into your tool.

However, for personal projects with few (if any) other developers, it’s not unreasonable to use Dropbox to store your repositories and make them more readily available. The backup and global access to your files could help make it easier for you to do your development work. This model breaks down with larger teams working on the project.

You’re not missing anything about Dropbox. It’s great for sharing files, and occasionally useful to recover a file that someone has deleted or updated by accident. But it shouldn’t ever be relied on as a source control application. Never.

At best, when you’re working alone and you want your files available everywhere, it’s still not as good as a Git/Mercurial repository, because you can’t batch changes and publish them with a single comment (so you can figure out later what you were doing).

What you’re missing is BitBucket, where you can have free private Git/Mercurial repositories with up to 5 collaborators. Once you’re above that number of developers, you need to think about whether to pay for an IT department or pay for BitBucket’s extended service, but by that point you’re WAY beyond being able to get away with DropBox.

Setting up your repository is about as complicated as sharing a DropBox folder.

As Thomas pointed out, you would lose some features that are relied on heavily in team environments. If your goal is to have a file share that is super-simple, it would work. If your goal is to avoid a real version control system at all costs, it would work.

You could use them together. Have the functionality of version control that utilizes the file sharing (price and privacy, sharing may cost more?) across multiple devices of DropBox. I’ve never done it, but here is a link: http://rogerstringer.com/2012/04/16/using-dropbox-as-a-git-repository.

It can be technically used as version control, similar to making a tar.gz/zip file after every change can be used as version control. Which is probably not the best method to go about doing things, even if you include a changelog with every change and zipfile.

It won’t include support for things like comparing and diff’ing two different versions, merging different versions, having multiple concurrent branches that you can work on with a simple “git branch” to choose between them, and a list of other features that I am not immediately thinking of. I’ve done the “zipfile at the end of every feature change” method before and it’s clearly better than nothing, but personally I recommend using a proper tool for the job.

I’ll go against the trend and argue that it can prove useful in certain cases.

While I fully agree that Dropbox is in no way a substitute for a proper VCS, it can come in handy when it comes to sharing binary files with others on the team.

The most obvious case is images. The guys whose task is to come up with several different designs for, say, a button on a webapp, will want to share a few psd files, which will then be reviewed by the one who’s going to make the call.

Now, while committing assets such as images to source control is definitely worthwhile, throwing in all the intermediate versions isn’t going to buy you anything, all the while making your repository bloated (which is especially true if you’re using a DVCS). Nevertheless, Dropbox having some sort of rudimentary source control capability, you can still see the history of a file.

So yeah, I think that Dropbox (or Google Drive or whatever) can find its place in a team.