2005-10-19 13:42:05 UTC
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
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
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.