lkml.org 
[lkml]   [1999]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: revision control for the kernel (BitKeeper)
    Date
    : It would be nice, if it was possible to not have the full kernel with it's
    : history in the archive/repository, but only the versions since a certain
    : date/revision, say 2.0.0 or 2.2.0 e.g.

    Here's the reply to this question, this was discussed on the
    kernel@bitmover.com alias.


    To: kernel@bitmover.com
    From: lm@bitmover.com (Larry McVoy)
    Subject: Re: revision control for the kernel (BitKeeper)
    Date: Sun, 21 Feb 1999 19:44:35 -0800

    Linus Torvalds <torvalds@transmeta.com>:
    : Then you come back, and you have created various new patches while you
    : were away (making versions 2.3.129 and 2.3.130), so you just synch it all
    : back (and now the complete version contains everything from 2.2.x to
    : 2.3.130)
    :
    : With the collapsed version, you wouldn't have version information, but
    : hey, that's cool, you just wanted a temporary smaller repository anyway.

    I went off and did the numbers, which is what I should have done up
    front. I can do better than that and with one heck of a lot less work.
    Here are the numbers. Suppose you went through a big source base such
    as the kernel, which had 10 years of history. For each file, dig out
    each of the following sizes:

    gotten file (i.e., checked out version)
    revision history file (RCS or SCCS, they are about the same)
    gzip -4 < revision history file

    You will get ratios like

    3.8 gotten file
    7.65 SCCS file
    1 gzipped SCCS file

    So what's that tell us? The top of trunk checked version is approximately
    1/2 the size of the entire revision control file. So even if I pruned
    all the way up to the top of trunk, we get a 50% savings.

    On the other hand, if we gzip -4 the SCCS file, we get almost a 4x space
    savings, or a space savings of 75% instead of 50% to put in the same
    terms as above.

    The cool things are
    - I can give you guys all the revision history
    - the size on disk is 1/2 what it would be compared to the pruned
    SCCS file and 1/4 what it would be compared to the uncompressed
    SCCS file (this is a win in terms of disk I/O).
    - it is way less work for me (I am particularly fond of this point)

    So, sorry to rattle your cage about sizes, I should have ran these
    numbers first, but they are very strongly pointing towards compression.
    I just went and did some timings to make sure gzip is fast enough.
    I can uncompress a 1.2 MB file (from .2M -> 1.2M) in 100 milliseconds
    (aka an effective rate of 12MB/sec) on a 300Mhz K6. Going the other
    way is slower, about 4MB/sec. But that's reasonable, it means that a
    reasonably high end machine can keep up with the disk arm.

    So this long rant says compression rocks. Did I miss anything?

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:3.471 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site