From owner-freebsd-current Mon Nov 2 04:13:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01143 for freebsd-current-outgoing; Mon, 2 Nov 1998 04:13:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01137 for ; Mon, 2 Nov 1998 04:13:03 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.0]) by smtp03.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA25FE; Mon, 2 Nov 1998 13:12:55 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19981102003426.04544@follo.net> Date: Mon, 02 Nov 1998 13:16:54 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Eivind Eklund , John Polstra Subject: Re: kernel compile problem Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, Peter Wemm , Leif Neland Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Nov-98 Eivind Eklund wrote: > On Mon, Nov 02, 1998 at 12:23:42AM +0100, Jeroen Ruigrok/Asmodai wrote: >> Except the Daemon (in this case the Oracle database) allowed the changes. >> That's what I meant with the CVSupd too... The committer is expected to comm >> it. The Daemon is expected to handle all the administivia of the >> allowance/versioning. Hope this makes it clearer for the both of us. And the >> others offcourse =) > > Sorry - this discussion is getting sort of useless. It _is_ possible > to handle this within cvs/cvsup, but if we are to do that, we will > have to create a lock for a single commit, and have cvsup grab the > previous version if this lock is present (a commit is in progress). > Making this will be a large set of changes both to cvs and cvsup. Due > to the time available to the relevant developers, I believe this is to > be very unlikely to happen. Besides this, I believe it would be less > work to replace all of cvs and cvsup than to implement this within the > present framework (if we allow the replacement to work against a real > database instead of working with a self-made database). Well, then my vote for starting on a new cvsup(d) which uses a real database is in. Not that I am not satisfied with the current version, but as ye all know: most things can be improved upon. However the problem is the gradual migration from one cvsup platform to another. People will always complain about why it had to change. I will be most happy to donate time and work on this effort should others care to do likewise. Then again, with the migration of ELF nearing, why shouldn't we scare the world some more? *g* regards, --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message