Re: revision control for the kernel (BitKeeper)

Larry McVoy (lm@bitmover.com)
Mon, 22 Feb 1999 10:35:20 -0800


: With respect, I think you did. Compression rock, but is IMHO orthogonal to the
: question. Many people who are short of space will be using e2compr anyway, and
: compression won't gain them a thing.
:
: Now, if you show that Bitmover files compress better than SCCS files, and that
: the compressed size of a full Bitmover history is smaller than the compressed
: size of a pruned SCCS history, that's different.

I think this is a pointless argument, but I'm happy to show numbers.

Ratio what
.6 gzipped top of trunk checked out file
2.1 top of trunk checked out file
1.0 gzipped SCCS file with all history
4.1 SCCS file with all history

So what's that tell us? It says that if we just gzip the SCCS file, we get a
75% space savings. If I were to prune all the history off, I'd get an 85%
space savings, or an additional 10% or so.

The reasoning is that the SCCS file, if pruned, would be close to the size
of the top of trunk checked out file, so using the gzipped top of trunk is
a reasonable approximation.

I fail to see the value of pruning the history. Ever. For 10% space
savings? That's completely pointless, especially when you consider that
we are already turning what is about a gigabyte into around 60MB and then
turning that into about 15MB. So you want another 1.5MB chopped off and
you are willing to give up all the history to get it? I'm not.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/