[Top][All Lists]

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

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

From: Bruce Stephens
Subject: Re: [Gnu-arch-users] archive storage format comments on the size
Date: Tue, 30 Sep 2003 00:03:19 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

Andrea Arcangeli <address@hidden> writes:


>>    The space inefficiences in arch are that it adds: contents of
>>    deleted lines and files, context of diffs, an extra copy of 
>>    the log file, and some overhead costs associated with using
> why can't the not strictly needed stuff be removed? We know the
> patchsets can't reject during checkout, why should we carry all this
> overhead with us when that can be deduced at runtime? Is it feasible
> to regenerate at runtime? I was thinking starting with a diff -u0. I
> believe the only case where we need a larger diff is when we call
> the merging (the -u paramter effectively controls how strict the
> patch should be and -u3 is a normal good default), we never need
> anything bigger than -u0 never during checkouts, and the merging
> isn't that performance critical.

I think some of that dates from the shellscript proof-of-concept days.
Kindof, anyway.  The idea of keeping patch-logs as just part of the
source tree, anyway.  On the other hand, it provides redundancy, which
is sometimes useful.  And it allows versioned modification of
comments, which is potentially cool, although potentially very

If someone were to design a system from scratch (and weren't trying to
write in shellscript) then probably they'd separate out the metadata
(the CM-stuff, like the patch-logs), and store them separately.  And
really, the patch-logs don't need to be versioned.


reply via email to

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