Date: Sun, 1 Nov 1998 07:02:10 -0600 (CST) From: User RKW <rkw@nomad.dataplex.net> To: Joe Abley <jabley@clear.co.nz> Cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel compile problem Message-ID: <Pine.BSF.4.05.9811010633120.8635-100000@nomad.dataplex.net> In-Reply-To: <19981101225954.A29897@clear.co.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
>From the point of view of the users, a locking mechanism along these lines would be fine. However, there are SERIOUS complications relating to the archiving and distribution of the source tree. If the locks are maintained as files in the tree, they would further bloat the already unwieldly tree. I do like the idea of having bsd.subdir.mk recognize parts of the tree to avoid. However, the locks, as described, are likely to get in the way of the developer who is testing his changes in order to decide if he can release the lock. On Sun, 1 Nov 1998, Joe Abley wrote: > On Sun, Nov 01, 1998 at 07:44:52AM +0100, Leif Neland wrote: > > > > Is the problem that committing isn't 'atomical'? Generally, yes. Worse, a commiter sometimes makes faulty updates which, although he thinks that they are complete, are missing something. This may well be the result of differences in his environment and that of someone who is extracting from the master tree. > How about a directory called "lock" in whatever part of the source tree > is appropriate, ".locks" might be more appropriate. > into which committers deposit a file named with their e-mail > address, containing a description of why the source tree is locked? > > 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). > > If no "lock" subdirectory is present, this should be interpreted as > "there are no locks for this branch". > > Just an idea :) Whaddayathink? 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. Another approach would be to place the cvsup distribution behind a transaction processor which would serially commit atomic changes. 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.9811010633120.8635-100000>