Date: Mon, 16 Nov 1998 21:50:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rkw@nomad.dataplex.net (User RKW) Cc: jabley@clear.co.nz, freebsd-current@FreeBSD.ORG Subject: Re: kernel compile problem Message-ID: <199811162150.OAA04517@usr08.primenet.com> In-Reply-To: <Pine.BSF.4.05.9811010633120.8635-100000@nomad.dataplex.net> from "User RKW" at Nov 1, 98 07:02:10 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry (and I) would argue that the committer should not be allowed to > remove the lock himself. That privledge/duty would belong to the QA > dept whose daemon would make at least some rudimentary checks before > pulling the lock. No. I would allow the user to remove the lock; as in: cvs lock w cvs ci cvs unlock Where the cvs unlock forced you to comment on the content of your commit, as a group (I would subscribe to *only* the list of log messages from this, if it were available). The QA issue is one of forcing developers to test-build before doing commits, as in: cvs lock w cvs update make # modify code and repeat previous command, as necesssary cvs ci cvs unlock This is a developer thing. You could also do: cvs lock r cvs update cvs unlock ...a read lock; the lock does not force a comment. You could also do: cvs update ...with no read lock. Obviously, most developers would do this, while cvsup would mirror the latter. This has effectively been discussed to death before; most committers are unwilling to type the two additional CVS commands, and they fear that concurrent developement would be stymied (the lock should apply against the module, so this is a specious argument given the infrequency of concurrent commits). The purpose of the locks is *only* to ensure complete snapshots, so that buildability is a function of the contents of the tree not currently undergoing modification by a developer instead of a mater of chance. If you are going to talk about hacking up cvs and cvsup, the single most useful hack would be to allow the cvsup of the FreeBSD sources directly into a local vendor branch, such that you could make local modifications to the source tree without fear of getting stomped, and (unlike the "magic revision" hack for supporting local changes) you would have a simple method of "merge-to-head" to update your code to track FreeBSD's progress. Unfortunately, it's been years since I've done Modula II, and cvsup is in Modula III anyway... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199811162150.OAA04517>