Date: Fri, 17 May 1996 13:44:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@Glue.umd.edu (Chuck Robey) Cc: rkw@dataplex.net, freebsd-current@FreeBSD.ORG, hackers@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, nate@sri.MT.net Subject: Re: Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD Message-ID: <199605172044.NAA20637@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.91.960517095339.26702B-100000@maryann.eng.umd.edu> from "Chuck Robey" at May 17, 96 09:59:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I hope there is somebody out there who cares about the difficulties of the > > "average joe" and doesn't simply brush off those problems because they are a > > member of the elite class who get to play by their own rules. > > If you would make clear that your realize that your comments don't apply > to those who are net connected, you wouldn't have everyone complaining. > Your comments so far have been incorrect in how sup and ctm really work. > No one would argue about upgrading ctm, but you seem to be making claims > about both sup and ctm that don't apply to both. Actually, I am net connected, but I do not have commit privs. I have some strong objections to using the CVS tree as an experimental code communcation medium for a working group, even if I did have commit privs. I agree with him. There are problems for the programmer without commit priviledges; specifically, I can't have both local source code control for my changes and have up to date integration of other's changes at the same time. Where I differ is that I believe this is a *purely* CTM/SUP problem, because of the way updates are made by these tools. It isn't clear to me whether CVS itself can support the concepts necessary to fix the problem, in any case. The other issue that I disagree on is more one of policy enforcement than anything else. At Novell, we used CVS for tree maintenance, but we supported a multiple reader/single writer locking mechanism. You could checkout sources without acquiring a reader lock, but doing so put you at risk of having an unbuildable source tree. A writer lock could not be acquired while a reader lock was asserted, and vice versa. The correct method of making a tree snapshot for SUP or CTM such that the resulting tree is guaranteed to be guildable is to not release the writer lock until the tree builds. A writer lock is followed by a CVS update, conflict resoloution, a test build, and delta checking The CVS tree should be buildable at all revision tag levels. Period. This would drop 33% of the SUP overhead off of Freefall immediately, and 50% of the SUP overhead on the mirrors, as updates are not required to be retried. It would also make FreeBSD look better. It would be impossible to check out an unbuildable tree following a SUP. No more "xxx breaks yyy" traffic on -current (at least for structural changes to the build environment). Policy has little or nothing to do with implementation. The reason I suggested locking was as a means of implementing the policy. It is not the only means, and personal restraint is obviously possible. if the integration update policy is followed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605172044.NAA20637>