Date: Sat, 18 Apr 1998 08:27:58 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: Eivind Eklund <eivind@yes.no> Cc: Greg Lehey <grog@lemis.com>, Karl Pielorz <kpielorz@tdx.co.uk>, current@FreeBSD.ORG Subject: Re: Quick Question re: Dmesg & Current Version Message-ID: <l03130300b15e553065b4@[208.2.87.6]> In-Reply-To: <19980418140954.28168@follo.net> References: <l03130300b15e08da98d4@[208.2.87.4]>; from Richard Wackerbarth on Sat, Apr 18, 1998 at 02:47:58AM -0500 <353802A2.CB67FCE7@tdx.co.uk>; <353802A2.CB67FCE7@tdx.co.uk> <19980418113504.U1090@freebie.lemis.com> <l03130300b15e08da98d4@[208.2.87.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:09 AM -0500 4/18/98, Eivind Eklund wrote: >On Sat, Apr 18, 1998 at 02:47:58AM -0500, Richard Wackerbarth wrote: >> At 9:05 PM -0500 4/17/98, Greg Lehey wrote: >> >On Sat, 18 April 1998 at 2:32:18 +0100, Karl Pielorz wrote: >> >> I'm just starting to get to grips with CVSup - is there anywhere it >>stores >> >> the date & time that the source was last updated? - Rather than the last >> >> build time? >> > >> >Somewhere, probably. When I used ctm, I modified /sys/conf/newvers.sh >> >to include the ctm update number in the header, but I haven't found >> >anything useful in the CVS database. Let me know if you do. >> >> Nope. AFAIK, there is nothing there. What is needed is something generated >> at the MASTER source and propogated through all the distribution chains. >> >> I wrote such a change last year, but it was promptly rejected on what I >> can only conclude were political grounds. (The supposed "technical grounds" >> were bogus arguments.) Perhaps someone with some clout will reconsider :-( > >(Richard, please don't take this personally) I was in favour of >reaching Richard's goal (and I think all of us where), but saw Nate's >arguments as fully convincing. Loosing information if you loose a >race is not acceptable for a production system as large as FreeBSD. > >I'd be glad if you looked into providing a solution for the problems >with your change, and will try to get the change in if you do so. AFAIK, Nate's objections were that I did not automate the recognition of new branches and that the mechanism that I was using to manually add a new branch was "overly dangerous" in that it could cause problems if someone made a mistake. As far as the "race" condition that you mention is concerned, that is solved by doing the steps in the proper order. While, early on, I conceeded that the process would be better if I simplified the insertion, I don't think that REQUIRING that is essential for a "first cut". I happen to disagree with Nate about the desirability of automatically recognizing new branches. IMHO, that configuration should be a manual step. I have been unable to get Nate to give me any explicit set of steps that breaks things in the manner that he claims. I do not consider it "broken" if someone creates a new branch and the file exists for a short time and then disappears. CVS will complain when that individual does his next update. However, the complaint is that the file no longer exists. This is a proper complaint. The problem should be fixed either by deleting the file or installing the branch in the list of branches that are being tracked. One reason that I am reluctant to automate the creation of new branches is that I am uncertain that our overall design is correct. We may need to have a different mechanism which tracks, in its output, stamps for multiple branches. For example, we may need to track "soft updates" separately from the main kernel by having more than one file appear when you select that sub-branch. Using the manufacture of automobiles as an analogy, I have hand-built a "concept car". I think that we should "road test" the design before we create the tooling for an assembly line. If someone is willing to address the present situation and get things out of the stalemate by either demonstrating, as opposed to simply alledging, a critical problem OR by getting the code accepted, I would certainly be willing to work with them. Richard Wackerbarth 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?l03130300b15e553065b4>