Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jun 1997 12:13:55 -0700
From:      John Polstra <jdp@polstra.com>
To:        mark@quickweb.com
Cc:        hackers@freebsd.org
Subject:   Re: make world error in RELENG_2_2
Message-ID:  <199706201913.MAA12625@austin.polstra.com>
In-Reply-To: <19970620120938.27122@vinyl.quickweb.com>
References:  <m0wevep-000A41C@TomQNX.tomqnx.com> <26359.866788909@time.cdrom.com> <19970620120938.27122@vinyl.quickweb.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706201913.MAA12625>