gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Arcangeli
Subject: Re: [Gnu-arch-users] archive storage format comments on the size
Date: Tue, 30 Sep 2003 19:54:38 +0200
User-agent: Mutt/1.4.1i

On Tue, Sep 30, 2003 at 10:28:25AM -0700, Tom Lord wrote:
> If you have an idea to present, please make an effort to present it in
> a manner that convinces me you have made an effort to express your
> idea concisely and clearly, and made an effort to "get" how more

I think I already did. That was the email you answered to, that's why I
found your complain ironic when posted to such an email.

> At least one linux kernel hacker has used it since the days of larch.

I already told you with the patches and pre-patches it's next to trivial, 
there are at most 1000 patches to merge and they're big so they will
compress much more than x2 with your current model, so the archive could
be even smaller than an uncompressed cvs repository that way. Ask him if
he had anything close to 13000 tiny patchsets in his 2.5 tree that
compresses at most x2, like I will need and I already have today compact
in 450M of _uncompressed_ cvs.

the only comment from a kernel hacker I read so far is from Davide and
he finished with:

        Performance can be improved, and the rest looks great ! :) 

I agree with him, performance to me means as well fetching the 13000
changesets efficiently (not a cacherev that loses info). My problem
besides performance is also the size of the archive, but both are
strictly related, and cacherevs are just a workaround that tends to hide
the underlying problem in the current format of the archive (I mean, the
granular one that stores all the info).

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]