Thanks for all the replies. Yeah, I figured this wouldn't be a good idea. There's no way to prevent multiple users from simultaneous updates. Even if Subversion could allow multiple svnserves hitting the same repository by tracking lock files, you'd still have an issue with Dropbox latency issues. Dropbox is pretty fast at updating other user's computers, but it isn't instantaneous.
Having a publicly available Subversion repository is the best way. The problem is what do you do if you don't have that. I do keep my personal repository in Dropbox, and I do run separate svnserve processes on all the machines I use pointing to that repository.But, I'm not worried about sync collisions. I'm only on one box at a time. For multi-user projects, I've used Git. I keep the main Git repository is accessible via Dropbox, and everyone is suppose to be able to pull from it, but they're not suppose to push changes directly to the Dropbox repository. Instead, they're suppose to email me the patches, and I'll push them back to the Dropbox repository. I'm not a big fan of Git. Tracking patches and diffs is not the same as version control, and Git is just not as user friendly or as polished. However, there are times when having a distributed revision control system is nice. I can see why many open source projects use Git. I am still not convinced that Git is good in corporate environments. In those places, you want a centralized repository and the control it gives you. As I told one Git advocate. If you run an open source project, and a million people have a copy of your repository, that's good. If run a development shop building a proprietary trading application for a large financial firm, and a million people have a copy of your repository, that's bad. -- David Weintraub qazw...@gmail.com
