Date: Sun, 01 Nov 1998 20:06:59 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Joe Abley <jabley@clear.co.nz>, John Polstra <jdp@polstra.com> Cc: freebsd-current@FreeBSD.ORG Subject: CVSup(d) (was: Re: kernel compile problem) Message-ID: <XFMail.981101200659.asmodai@wxs.nl> In-Reply-To: <19981101225954.A29897@clear.co.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981101200659.asmodai>