Thor Lancelot Simon <tls@rek.tjls.com> writes:
> We experimented with it: one of the NetBSD developers spent a lot of time
> fixing cvs2svn so it would import our repository _at all_ without crashing,

Er, who was that? BTW, cvs2svn won't "crash" on our repository and
never would -- it isn't written in C. It just runs far too slowly and
has some other issues with its ability to cope with our repo.

> and then discovered that the resulting Subversion repository was four times
> as large as the original CVS repository had been.

Dunno about that, but it is sort of irrelevant, because...

> In other words, we'd need a machine with 32GB of memory to keep it in RAM.

But we wouldn't need to keep it in RAM, because subversion is
dramatically more efficient. It doesn't need to go through the entire
repository in order to update a client the way CVS does -- it knows
the change set it wants to get its hands on and simply retrieves it,
and it has an efficient data structure for doing so. With CVS, the i/o
needed is proportional to the size of the repository, but with
subversion, the i/o is proportional to the size of the change between
the versions, which you would agree is much more sane.

Because the size of the deltas being retrieved is generally quite
modest, even with merely decent disk performance we could manage far
more clients than we do now with an entirely RAM cached repository.

Perry