Re: Use of svnserve and Dropbox

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