Re: [Gnu-arch-users] archive storage format comments on the size

[Andrea Arcangeli]

On Tue, Sep 30, 2003 at 12:50:55AM +0200, Andrea Arcangeli wrote:
> different .tar.gz). In short I believe the superpatchset it's very
> preferable not just for space compression, but for checkout performance
> too. Oh, it'd better be in bzip2 format (possibly selectable optionally,
> that will crunch another 20% of space or so).

I forgot to tell one last important property of the superpatchset, the
superpatchset will be a killer of network bandwidth too, that will be
the most noticeable in practice (assuming you're not already crying for
disk space), it'll reduce a remote checkout from a ~30M transfer to a
~3M transfer in my case (assuming the superpatchset compressed as
bzip2). Even more important, it's not only a reduction in data
transferred, but it'll make sure to never wait a RTT before being able
to get more data, it'll keep the tcp pipe filled, since the file
transferred via http or ftp will be huge, unlike the current tiny
tar.gz.  That can effectively avoid any urgency in writing a real
transfer protocol to properly compress data.

Then, after the remote checkout, you'll have the option to split the
superpatchset in granular pieces again on your local filesystem. For
simplicity you can teach arch to complain if somebody pretends to star
merge or update across a superpatchset. The superpatchset makes sense
only for the "main" repository for the very old patchsets that you're
not going to merge against anylonger, so it's acceptable to ask the user
who's merging that he needs to split the superpatchset first if he
really wants to merge patchsets in the middle of the superpatchset.

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/