This may be nothing new, but I chatted with Ben Collins-Sussman as OSCON
last week. He's one of the subversion authors, and hadn't heard about
NetBSD's difficulties while considering svn as a possible cvs
replacement.

1) On the topic of cvs2svn, he said that other large projects like KDE
and Gnome did need a machine with lots of RAM and letting it run for a
week to complete.

2) On the topic of repository size, he said that native svn repos should
not be significantly larger than native cvs repos. However, repos
converted by cvs2svn suffer with every branch. Since cvs does not record
branch creation time, cvs2svn does not use svn branching functionality
during the conversion, but instead copies each file. Hence the resulting
repo will be larger than needed by a copy of every file for every branch
it is on.

I assume that also means that the files are 'associated' the way that we
would expect them to be in cvs.

I suggested that perhaps if we determined the branch information
manually (and from the BRANCHES file) that someone might be able to
modify cvs2svn to use that input and generate an optimal svn repo. He
agreed that should be possible, but seemed surprised that we cared about
the history that much. Apparently some other projects just converted the
head of development and say 'look back in CVS for the old stuff'.

3) On the topic of repository size, and its detrimental effect on
servers, particularly with regard to offering rsync, Ben suggested that
the existing svnsync might not have that problem, and would be a more
efficient sync mechanism in bandwidth as well as RAM, in part because it
knows the structure of the svn repo and takes advantage of it.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Although some of you out
there might find a microwave oven controlled by a Unix system an attractive
idea, controlling a microwave oven is easily accomplished with the smallest
of microcontrollers. - Russ Hersch - (Microcontroller primer and FAQ)