Richard, - I commit multiple files at once with TortoiseCVS all the time. Yes, but they're separate commits. If someone else is getting files from CVS while you're committing changes, they may get an incomplete change--some files from before your commit, some files from after. With Subversion, this can't happen; each commit--no matter how many files--is atomic. And they're automatically grouped together, rather than a series of several (hopefully related) commits. I have used this to successfully commit thousands of files at once. - In reading through the SubVersion manual, it doesn't seem any - different than CVS from a user's perspective, except in the way - that version numbers are assigned. Mostly that is true, especially since that was a primary design goal of Subversion. - I was guessing we'd use - - svn+ssh://bazooka.dreamhost.com/users/twegner/fractint/fractsvn/ - - as the base URL for the SVN repository. According to the documentation, this is the svnserve process using an SSH-encrypted tunnel. This is not the same thing as local file access, since it requires the svnserve process to be set up. (I've never set one of these up; so far, I've always used either file:// URLs or DAV.) - Ah, OK, I guess the manual is a little out of date then. Not necessarily. The latest Subversion is 1.4.3 (which has a weird incompatibility with Apache 2.2.4 and DAV over SSL with client certificates and CNs as usernames; 1.4.2 doesn't have this problem, and neither does Apache 2.0.59). What I have noticed is that many pre-packaged distributions (Debian stable, Red Hat Enterprise Linux, I'm talking about you) still come with much older versions of Subversion, 1.1.x or 1.2.x. These versions will still work just fine, but 1.4.x offers substantial performance improvements. Compiling a custom Subversion package is a pain, however, as there are lots of library dependencies with their own sets of dependencies. Tim, - For the record, that was indeed what I meant. That is, you meant accessing the repository through the local filesystem (file:// URLs), not necessarily using the fsfs back-end repository storage, which is largely transparent to the way you actually use the repository. What I've noticed when running Subversion with local repositories is that regardless of the back-end storage, Subversion expects that you have access to the repository files, and doesn't deal with things well if you don't. So you could set up a group, assign developers to it, and then create the repository owned by the group... but if *anything* lacks group write access, Subversion can choke. One wrong umask and you've got to fix it. I solved this by wrapping the svn binaries with simple scripts that force the umask to something sane, then invoke svn as before. The repository then gets set up with group write access as it should, but the rest of my files can keep their group-not-writable setting. I can explain more if you like; the docs are... muddy about this. Since I've been using Subversion through a command line I've not had a pressing need to set up TortoiseSVN. It's on my list of things to do. - At work we use the fsfs system and it works great. In studying - the documentation I couldn't see any advantage to bdb. One major advantage: if you frequently do very large commits over a network with a very short idle timeout (e.g. through a NAT box), you can get timeouts with fsfs at the end of the commit as the data transfer happens at the beginning of the transaction and then the connection is silent for a long time. (Yes, I've done this.) With BDB it spreads out the data transfer more evenly and timeouts don't happen. Other than that, fsfs is more flexible all around. That particular choice isn't even that critical; to change formats, one simply dumps the repository to a portable format, recreates it with the new storage type, and re-imports from the dump. As easy as 3.1415926353897932384626433832795... Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/