Rich, - I think its all irrelevant to the clients. That's all an - implementation detail on the server side (Berkeley DB or file). I don't think Tim was referring to the repository storage method (bdb or fsfs) but rather the way in which users check in code. With CVS each file is checked in (there are no atomic multi-file commits) and you can just use Subversion like this too. Later, as you become more comfortable with Subversion, you can try committing multiple files at once... and it just works. There's also the issue of how access to the repository itself is granted. If you're on the same host as the repository, you can access it via file:// URLs, and the client programs simply use local filesystem calls (this is the ra_local module). If you're not on the same host, or are but want to isolate yourself from the repository for some reason, you can use svnserve to provide access via svn:// URLs (ra_svn module) or use Apache and DAV to provide access via http:// URLs (ra_dav module). The storage mechanism used is largely a matter of personal taste. In my opinion, the fsfs storage is just fine; there's less (zero) possibility of the repository becoming "wedged", and you can always get a consistent repository snapshot without extra processes, which is great for backups. A run-down of the differences can be found here: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.repo sadmin.basics.backends Note that as of Subversion 1.2, fsfs is the default, even though they explicitly state neither is more official than the other. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/