programming, electronics, beer, food.
$> svn co svn://gcc.gnu.org/svn/gcc/trunk gcc$> cd gcc$> du -h...1.6G .$> svn export . ../clean-gcc$> cd ../clean-gcc$> du -h...638M .$>
Disk space is cheap. Subversion keeps a pristine copy of everything in the repository. That's so you don't have to suck up your entire downstream bandwidth, or put an unnecessary load on a server in order to find out what you've changed. I'm sure those aren't the only reasons, but they're the ones I can name off the top of my head.BTW, you should tweak your stylesheet. Faint-green on a white background doesn't show at all. Ideally, people shouldn't have to highlight the text in order to read it.
Disk space is cheap. So why not store the entire history on local disk? git, mercurial, and company are able to store the full project's history on disk in a similar amount of space as an svn checkout.svn is a fine scm if you look at it in isolation, but when placed next to everything else available, it's sorely lacking.
> git, mercurial, and company are able to store the full project’s history on disk in a similar amount of space as an svn checkout.Not once the space occupied by a project's history and revision trees are significantly greater than the size of the head of the project.Besides, if git et al do that, why are you complaining about how much space subversion uses?
>Not once the space occupied by a project’s history and revision trees are significantly greater than the size of the head of the project.It's going to be a lot of history before that happens.> Besides, if git et al do that, why are you complaining about how much space subversion uses?Precisely because of this. If git is able to keep the entire history plus checkout in similar space as an svn checkout, then obviously svn is doing something wrong.Keith Packard has a good write-up on the matter:http://keithp.com/blog/Repository_Formats_Matter.html