Date: Sun, 01 Nov 1998 19:44:26 +0100 (CET) From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Leif Neland <leifn@swimsuit.internet.dk> Cc: Dmitry Valdov <dv@dv.ru>, freebsd-current@FreeBSD.ORG, Peter Wemm <peter@netplex.com.au> Subject: Re: kernel compile problem Message-ID: <XFMail.981101194426.asmodai@wxs.nl> In-Reply-To: <Pine.BSF.4.05.9811010654560.3668-100000@gina.swimsuit.internet.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-Nov-98 Leif Neland wrote: >> > You got a cvsup in between commits.. Try again and you should be OK. >> >> just spotted this one too ;) >> >> How can ye make sure ye ain't between commits? cvsup it about 15-30 minutes >> later and try again to make? >> > 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. Nah, that wouldn't work that well... > 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... Exactly, then ye are going against what makes the commit system of cvsup work. > To make it more clean, it should be done in cvsupd and perhaps cvsup. > > It could be implemented by modifying using cvsupd's ability to check out > the version of the tree as it were on a certain time. > > The committer sends it a command/file/signal, and then new additions > made after that time is not seen by someone who requests the latest > versions. Exactly, does the term commit-relay express the idea completely? > After everything is committed, the committer removes the lock. Why the commiter? Make it so that the cvsupd places a lock temporarily whenever a commit finds place. Then after the person is through with his or her commits it makes all those updated files available to the public for cvsup. Make it so that the daemon does the work and not the commiter. This saves hassle. > Perhaps this should lock be on committer-resolution, so one committer > forgetting a lock/being hit by an 18-wheeler won't lock the entire tree. Well, what does cvsup do? It monitors versions. So the lock must be based on versioning too... > If somebody _really_ wants the latest versions, one could specify an > date=-1 or something instead of date=. > > What happens if somebody starts a cvsup, and files gets committed before > the cvsup is finished? Are those updates seen? If the lock is removed within the current session it might. Depends on what the cvsup already fetched... > The tag date=. shouldn't mean "as late as possible", but "at the start of > this cvsup-run", so to get a consistent snapshot of the tree. That will solve the above problem. But the daemon must tag all the files or queue them for every cvsup to know which files to send to which connection. > cvsupd should keep track of each clients starttime, and not supply later > checkouts. Indeed. This may require significant improvements to cvsupd and cvsup. But they might make the whole process more stable at any given point in time. Comments? --- 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.981101194426.asmodai>