Date: Mon, 6 Nov 1995 11:35:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: rkw@dataplex.net, hackers@freefall.freebsd.org Subject: Re: 2.1.0-951104-SNAP is now available. Message-ID: <199511061835.LAA15560@phaeton.artisoft.com> In-Reply-To: <1563.815569274@time.cdrom.com> from "Jordan K. Hubbard" at Nov 5, 95 03:01:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> No kidding. I have been so desperate to get some sort of working > patch mechanism going (you wouldn't *believe* the number of requests I > get for this from people who quite understandably just want to update > their bits, not reinstall them from scratch) that I've even contemplated > the resurrection of the *patch kit*! > > Surely we can do something better than that? The patchkit operated on a "patch per feature" basis. CVS operates on a "patch per functional revision" basis. Well, at least it's supposed to all compile at any given revision. I don't think a "cvs diff -r rev1 -r rev2 -c" will produce a "per feature" patch unless features are committed one per revision. What was the greatest weakness of the patchkit (ordered install of dependent functionality) was also its greatest strength, at least for something like this. Unless you were willing to assert reader/writer locks such that a feature add was done by a single non-concurrent write, and limit adds to a per feature basis (lock tags being asswerted per writer lock session when the lock is released), then I can't see you being able to package up features on an individual basis. Doing so would mean procedural changes, some loss of concurrency on commits (but none on checkout unless you wanted to ensure a compilable code cut), and some additional work for committers, who'd be expected to break commits up on functional lines. I really think it wouldn't be worth it to you. You're still missing the revision dependency graphing tool to determine install order for revision based patches. Regards, 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?199511061835.LAA15560>