From owner-freebsd-hackers Fri Jun 20 12:14:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA19407 for hackers-outgoing; Fri, 20 Jun 1997 12:14:41 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19401 for ; Fri, 20 Jun 1997 12:14:34 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id MAA12625; Fri, 20 Jun 1997 12:13:55 -0700 (PDT) Message-Id: <199706201913.MAA12625@austin.polstra.com> To: mark@quickweb.com Subject: Re: make world error in RELENG_2_2 Newsgroups: polstra.freebsd.hackers In-Reply-To: <19970620120938.27122@vinyl.quickweb.com> References: <26359.866788909@time.cdrom.com> <19970620120938.27122@vinyl.quickweb.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Fri, 20 Jun 1997 12:13:55 -0700 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It's not a problem with cvsup. It's a fundamental flaw in the model > > of trying to "upgrade" a source tree by continually: > > > > a) Changing modified bits. > > b) Adding new ones. > > c) Not deleting the old ones. > > > > It's (c) which is the killer since you will eventually confuse the > > bezeesus out of the build system with old bits. Do you have the > > "delete" option turned on in your supfile? > > I turns out this is indeed the case... > [...] > I assumed that cvsup did (c) above, when it doesn't. You're certainly not the first person to get bitten by that. CVSup in general (exception described below) has the attitude, "If I didn't create it, I'm not allowed to delete it." Believe me, users get real offended if it behaves any other way. So things work just fine if you originally created your tree using CVSup. It knows it has the authority and the responsibility to clean up files that later get moved or deleted in the master source tree. When you have an existing source tree that was created by some other means, and you "adopt" it with CVSup, things get a little bit dicier. The exception I mentioned above does its best to deal with this scenario, but it's not perfect. Here's one way to adopt a tree that should work 100% fine: 1. Start with a definite known version of the source tree. Let's say it's FreeBSD-2.2.2-RELEASE, for example. 2. To adopt the tree accurately, do one CVSup update specifying the exact release that you have. In this case, you use "tag=RELENG_2_2_2_RELEASE". The update should of course make no changes to your tree. But it will have the side-effect of allowing CVSup to feel that it "owns" all of the files. (Its ability to "feel" is one of its many advanced features. :-) 3. Now change your tag to whatever you really want, e.g., "tag=RELENG_2_2" for -2.2-stable. Do another CVSup update. Any files that should be added or deleted will be handled properly. Trouble can arise if step 2 is skipped. Then, any files in your -2.2.2 tree that no longer exist in -stable are essentially considered unknown extra files and left alone. The greater the distance between your starting revision and the one you're trying to get to, the more of a problem this becomes. (As I describe this, I am thinking that I might be able to make it do better in a future release. I am also thinking that this would be a very good topic for discussion in the non-existent CVSup FAQ. :-) One final point -- I have to agree that you were ill-used by the orginal respondent. Hastening to add that he's a highly valued member of the development team, I nevertheless have to say that perhaps he's used up his patience reserve for "make world is broken" questions and should just stop answering them for a while. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth