Rich, - I just don't see how this (file:// URLs) could possibly work - given that the repository is *not* local, its on bazooka. Am - I missing something or are you just talking about some other - scenario and not what we would do for fractint? Tim mentioned file mode, which would work using file:// URLs if you were working by logging into bazooka. But you don't actually do your work on bazooka, so he was talking about using it via svn+ssh, which as he indicates in the docs works with very similar access controls as file URLs. I suspect the documentation that says svn+ssh is like svn but wrapped in ssh is wrong; that it is, in fact, like a local command line (not using svnserve) and the ssh just means to remotely log in and issue the commands. So what I said earlier about svn+ssh requiring the svnserve process is, I think, wrong. I was not necessarily speaking just about FractInt development--I was trying to share some of my other experiences with Subversion and the many different ways it can be set up. The permission issue is real. What it means is that everyone who has access to the repository has complete, unfettered access; you can commit anywhere in the source tree; you can destroy the entire repository. I doubt that's a problem for the FractInt team, since the odds of having a rogue developer are fairly small. In larger projects it does become an issue, and more complicated setups involving DAV allow you to restrict individual users to particular portions of the directory tree. Using DAV or svnserve also isolates developers from having direct access to the repository directory; they must work through Subversion to make changes. I honestly think that svn+ssh, as you've tested it, will be the best approach for FractInt. You still control access (by granting access to bazooka and including people in the group necessary to access the repository) but you get to use easy setup. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/