From owner-freebsd-hackers Thu Jan 9 21:22:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA18473 for hackers-outgoing; Thu, 9 Jan 1997 21:22:09 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA18468 for ; Thu, 9 Jan 1997 21:22:07 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id VAA01099 for ; Thu, 9 Jan 1997 21:22:49 -0800 (PST) Received: (qmail 5326 invoked by uid 110); 10 Jan 1997 05:21:14 -0000 Message-ID: <19970110052114.5325.qmail@suburbia.net> Subject: distfile diffs? To: hackers@freebsd.org Date: Fri, 10 Jan 1997 16:21:14 +1100 (EST) Cc: electron@suburbia.net (Ido Banks) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wonder whether the ports/cvsup could not be slightly modified to handle the fetching of diffs from one distfile version to another? For example the last three tar.gz versions of pine 3.xx were approximately 4000k a peice, while the diffs of the same were considerably less. The same goes for cvsup itself, and the modular-3 distribution (the entirety of which I've pulled across at least twice in order to satisfy cvsup's dependencies). For security and code-review reasons it would also be nice to have diffs for distfile version changes, rather than just yanking over the whole tree. Given that freefall sees copies of all distfiles (except for the occasional distribution restriction), it may as well be producing diffs from one version to the other. Whether this is done by placing unexploded tar balls under cvs control and letting cvsup or cvs rdiff do the work, or merely by generating diffs each time a new distfile tarball comes in from the old tarball and grabbing them with fetch(1) is an implementation issue. If the diffs are applied as part of the make process, and one presumes the port's object code make dependencies are valid, and the work dir has not yet been cleaned, re-compilation should be minimised. Cheers, Julian.