From owner-freebsd-current Sun Nov 1 11:03:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17716 for freebsd-current-outgoing; Sun, 1 Nov 1998 11:03:18 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17703 for ; Sun, 1 Nov 1998 11:03:14 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.72]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA1C03; Sun, 1 Nov 1998 19:03:07 +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: <19981101225954.A29897@clear.co.nz> Date: Sun, 01 Nov 1998 20:06:59 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Joe Abley , John Polstra Subject: CVSup(d) (was: Re: kernel compile problem) Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 01-Nov-98 Joe Abley wrote: > On Sun, Nov 01, 1998 at 07:44:52AM +0100, Leif Neland wrote: >> >> Is the problem that committing isn't 'atomical'? >> >> How about if the committer started by committing >> /usr/src/DONT_MAKE_WORLD_NOW >> then committed various stuff, then removed >> /usr/src/DONT_MAKE_WORLD_NOW >> This file could contain an explanation why the world shouldn't be made. >> >> The makefile should then check for the existance of this file. >> >> This could be implemented right now. It won't require updating cvsup and >> cvsupd. >> >> But this will give problems when several people are updating different >> parts of the tree... > > So we need a semaphore; however, a single lock file with a counter in it > doesn't sound very practical for cvsup. > > How about a directory called "lock" in whatever part of the source tree > is appropriate, into which committers deposit a file named with their e-mail > address, containing a description of why the source tree is locked? This will generate extra overhead and deletion of files. > bsd.subdir.mk could check for files within this subdirectory and fail > quoting the contents of any files that are present. > > The same branch of the tree could be locked by more than one committer > (since their respective lock files would have different names). > > Having lock directories at appropriate depths in the source tree would > be better than one "don't make world" lock file -- that way if I want > to rebuild and reinstall /usr/src/usr.bin/ I won't be affected by a > transient commit lock in /usr/src/usr.sbin/ (for example). Ye need to have it configurable at the lowest leaves possible instead of branches... > If no "lock" subdirectory is present, this should be interpreted as > "there are no locks for this branch". OK, what can we discern? 1) Need for multiple locks 2) The ability to cvsup a source tree that is commit free 3) The ability to commit changes regardless of the state of the tree 4) The ability for cvsupd to monitor versions every more carefully Did I miss somthing? --- 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