On Fri, 6 Oct 2000, Hubert Feyrer wrote:

> On Thu, 5 Oct 2000, David Brownlee wrote:
> > 	True, but how about putting all the patches into a single file -
> > 	that would certainly save on inodes and disk fragments... Maybe
> > 	even gzip it.
>
	Skip the gzip comment - I was getting carried away :)

> David,
>
> have you tried maintaining such a file? When you update a pkg to a new
> version, it's much easier, to apply one patch at a time and see if it
> fails is still needed or included in the new version. There's a reason we
> have the 'one file per patch' rule, and we're not going to sacrifice over
> some optimisation.

	I have updated packages and I tend to treat the patches as a
	complete set, though I can understand many may find it easier
	to apply them individually.

        Maintaining patches is eaiser with mkpatches - we should have
        a simple tool for applying patches and recording any problem
	to help when upgrading. It could even (optionall) stop after
	any problem to allow tweaking.

	We have	4418 patch-?? files, and 1061 patch-sum files.
	That could be reduced to 1061+1061.

	All in one file would speed things up and save disk and network
	bandwidth, and may well make the RCS logs more useful if anything -
	currently adding or removing a patch can result in a patch-?? file
	switching to refer to a different source file.

	Another (smaller) saving could be reached by putting 'patch-sum'
	into 'md5'. This makes more sense if we go to a single patch file
	as it would be less clutter in md5.

                David/absolute
			       -- www.netbsd.org: A pmap for every occasion --