Date: Sun, 1 Nov 1998 23:48:54 +0100 (CET) From: Leif Neland <leifn@swimsuit.internet.dk> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: Dmitry Valdov <dv@dv.ru>, freebsd-current@FreeBSD.ORG, Peter Wemm <peter@netplex.com.au> Subject: Re: kernel compile problem Message-ID: <Pine.BSF.4.05.9811012343110.1311-100000@gina.swimsuit.internet.dk> In-Reply-To: <XFMail.981101194426.asmodai@wxs.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? > Nah, not really... I don't understand the word... > > 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. > Not having done any committing, I guess a committer could make several changes in different parts of the tree, in smaller chunks. Only the committer will know when all the chunks have been committed. So only the committer should unlock the changes. As equivalent in the Oracle database, one session could make several changesin different table, but only after issuing a commit, all changes get visible for other sessions, and all at the same time. Leif 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?Pine.BSF.4.05.9811012343110.1311-100000>