1. The entire svn repo is currently 8.5 gig on disk (the cvs repo is 3.4 gig)
About 3 gig of this is crappy tag metadata (IE from tags that weird things have been done to, etc, so that cvs2svn can't simply make copies like subversion would have done originally). The svn repo also contains more history than the old cvs server, since it has old-gcc merged into it. I expect the repo to grow pretty slowly in reality (though 8.5 gig for 16 years isn't too bad). I'm working on patches for svn 1.4 that will reduce the repo size to about 4-5 gig (conservatively high) through better compression. 2. If you want context diffs, or support for -p, you need to configure an external diff. subversion's internal diff library always produces unidiffs. It is also not as featureful as gnu diff. It was built mainly so svn diff and friends would work without an external diff. I have a link to how to configure an external diff on the wiki page. It's really rather easy, and only has to be done once. There is no need to use -N, as svn add is a command that does not require write access. 3. Small operations (IE ls of random dirs, etc) are generally dominated by the ssh handshake time. Using ssh multiplexing will significantly speed these up. 4. For people using svk, the initial svk sync will probably take a while if you directly svk mirror. It's probably a ton faster to rsync the repo, svk mirror from that, and then change the source of the mirror (which should work fine, AFAIK). 5. Lastly, just to be clear, if you guys don't think the benefits outweigh the costs, we don't have to move. So far, the amount of dissent i've heard is pretty small, but please, if you don't want to move (or you do), please speak up, instead of silently suffering (or silently being in joy). Personally, i manage a bunch of branches, so subversion is a big win for me. It's nice to be able to merge and tag quickly and easily. It's nice to be able to pull the revisions to the mainline simply by using merge, instead of generating patches and reapplying them. It's nice to be able to rsync the repo without it touching 80 billion files. etc But if it's not a win for most of us, we probably shouldn't do it. There is no perfect revision control system. None of the currently production quality open source ones are any better. --Dan