On Tue, Dec 13, 2011 at 9:53 PM, J. Bruce Fields <bfields(a)redhat.com> wrote:
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.
What's the benefit of all the overhead (=growing size of the repos and
doing this as an extra step, not just uploading the tarball)?
Adding a VCS key [1] to the spec, so you can look at the uncompressed
source, which all of "vcs diff/grep", makes more sense to me. (This
only assumes upstreams repo will stay reachable.)
Unpackaging the tarball and adding a lot of data to the git repository
only makes it bigger and bigger and you can't really compare that git
repo to the upstream one (Maybe sharing some patches, but I guess no
pull etc will work).
Greetings,
Tom
[1]
http://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal