From owner-freebsd-hackers Mon Nov 6 10:39:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07508 for hackers-outgoing; Mon, 6 Nov 1995 10:39:55 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07492 for ; Mon, 6 Nov 1995 10:39:50 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15560; Mon, 6 Nov 1995 11:35:28 -0700 From: Terry Lambert Message-Id: <199511061835.LAA15560@phaeton.artisoft.com> Subject: Re: 2.1.0-951104-SNAP is now available. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 6 Nov 1995 11:35:28 -0700 (MST) Cc: rkw@dataplex.net, hackers@freefall.freebsd.org In-Reply-To: <1563.815569274@time.cdrom.com> from "Jordan K. Hubbard" at Nov 5, 95 03:01:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1733 Sender: owner-hackers@FreeBSD.org Precedence: bulk > 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.