Date: Tue, 6 Feb 1996 17:26:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@ref.tfs.com (Julian Elischer) Cc: terry@lambert.org, current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602070026.RAA03938@phaeton.artisoft.com> In-Reply-To: <199602062321.PAA01295@ref.tfs.com> from "Julian Elischer" at Feb 6, 96 03:21:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Ah yes but: > now that you have a sup+cvs setup, you can keep your diff sets up-to date > relatively easily, and if you send them as diffs > then there is a good chance that even if there is a time-lag induced > collision, it will be caught and fixed, > also many files get changes that are automatically resolved.. I have uploaded a FS_PATCHED.diff.gz to incoming on freefall. This was generated with "cvs diff -c" in /sys. The output doesn't look particularly useful as input to "patch", unless you write an awk/perl script to reformat the "cvs diff" file information (this seems to be more work than checking out a spamable tree). > as long as you don't check in your changes in your cvs tree, it's much > more resistant to spamming, to do it this way.. I don't check in my changes to my CVS tree. > > I can provide the changes as diffs if you need them that way; I'll warn > > you that you'll be in exactly the same boat applying them as the original > > diff sets I sent (that's why I went to the trouble of sup + cvs + ...). > > err why? See above. "cvs diff -c" does not result in a file that can be used as input to "patch" without some post-processing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602070026.RAA03938>