Date: Sun, 19 Nov 1995 12:04:15 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: "Garrett A. Wollman" <wollman@lcs.mit.edu> Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/pci if_de.c Message-ID: <Pine.BSF.3.91.951119114407.16172E-100000@jhome.DIALix.COM> In-Reply-To: <9511182218.AA32059@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Nov 1995, Garrett A. Wollman wrote: > <<On Sat, 18 Nov 1995 07:04:48 +0800 (WST), Peter Wemm <peter@jhome.DIALix.COM> said: > > > I think if we're going to distribute "patches", then we can't go past CTM > > for safety. You can guarantee that it will apply in it's entireity or > > not at all... > > Unfortunately, this highlights a fundamental brokenness of CTM for > distributing this sort of material: if the user has changed the file, > the delta won't apply, even if the patch is to a different part of the > file and therefore applies cleanly. Not Good. Yep. I think this would be the killer issue that could prevent us from goin that route. 1: CTM uses md5 checksums and complains loudly about them.. From memory you can "force" them though. 2: CTM uses ed-style deltas, not context diffs, meaning that if you force the delta to be applied, you'll most likely loose. 3: It's harder to manually apply the diffs... 4: It takes a large amount of disk space and cpu work to generate the deltas. (lack of disk space is the reason we're not doing -stable via ctm at the moment from memory). I doubt that these are unsolvable.. I dont see why mkCTM couldn't be changed to generate context diffs, or 'ctm' couldn't be changed to use 'patch' instead of 'ed' to apply them etc. I think we have two seperate needs here.. 1: We need (I think) a CTM of -stable when we get disk space so that we can have people keeping up to date automatically. We really need example configs for how to setup email aliases, scripts, etc etc. We *dont* want 10,000 people supping -stable... :-( 2: We need small, feature based patches. I doubt CTM would be the ideal tool for that, because that prevents people from making local changes without fear of being unable to use patches. I feel this implies an organised context diff wrapped in a shell script which checks checksums (and warns if they are wrong and asking if the user wants to attempt to proceed anyway) babysit's 'patch', does backups of the file, rolls back out of a failed patch, perhaps offers to recompile and reinstall the changed code if it's appropriate, or offers to recompile the GENERIC kernel if that's what they are using and so on. Easy, eh? :-) I most definately do not have the energy to do this, so I'm not volunteering.. I could help somebody else do it though. Cheers, -Peter > -GAWollman > > -- > Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... > wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. > Opinions not those of| It is a bond more powerful than absence. We like people > MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951119114407.16172E-100000>