Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)
J. Bruce Fields
bfields at redhat.com
Tue Dec 13 20:53:00 UTC 2011
On Tue, Dec 13, 2011 at 02:12:30PM -0500, Stephen Gallagher wrote:
> On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote:
> > On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote:
> > > To some extent I agree with both sgallagh's sentiment and the logical
> > > conclusion you're drawing. However, I think the lookaside cache is
> > > a necessary optimization/compromise to the ideal of putting everything into
> > > version control, though. Current technology would make it prohibitive in
> > > terms of packager time (and for some packages, space on developer's
> > > machines) to put tarballs into git as the cloned repository would then
> > > contain every single new tarball the package ever had.
> > I'd be curious to know how expensive that actually was.
> > I'd think delta-compression could make it quite reasonable for the
> > typical project. (Exceptions including things like games with lots of
> > binary data in each release.)
> Nearly all packages are released as a compressed tarball. So any change
> in the package is likely to result in a delta of the binary image that
> is close enough to 100% as makes no difference.
You'd want to uncompress before checking in. Or even expand before
checking in--"git diff" and "git grep" would then be a lot more useful.
You'd no longer have a copy of exactly what you downloaded, but someone
with a copy of the download could mechanically verify that you'd
imported the same content.
You could still keep the .tar.gz in the lookaside cache, but you
wouldn't normally need to go look at it.
More information about the devel