From owner-freebsd-current  Wed Dec  6 17:16:44 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id RAA15861
          for current-outgoing; Wed, 6 Dec 1995 17:16:44 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA15853
          for <current@freebsd.org>; Wed, 6 Dec 1995 17:16:33 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA02792; Wed, 6 Dec 1995 18:11:10 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199512070111.SAA02792@phaeton.artisoft.com>
Subject: Re: changes in -current..TEST please
To: davidg@root.com
Date: Wed, 6 Dec 1995 18:11:10 -0700 (MST)
Cc: terry@lambert.org, gibbs@freefall.freebsd.org, phk@critter.tfs.com,
        imb@scgt.oz.au, julian@ref.tfs.com, current@freebsd.org
In-Reply-To: <199512070054.QAA19195@corbin.Root.COM> from "David Greenman" at Dec 6, 95 04:54:12 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
Precedence: bulk

> >I am *NOT* deleting files!
> >
> >I am:
> >1)	SUP the CVS
> >2)	cd /sys
> >3)	cvs update .
> 
>    You should be using "cvs update -Pd".
> 
> >*BOOM*
> >
> >The problem occurs because the files do not exist in the first place, not
> >because they existed, but then I murdered them.
> >
> >
> >Are they supposed to be in my checked out copy of the tree?
> >
> >How does the CVS come to the conclusion that the should exist -- it checks
> >the repository data, right?
> 
>    Wrong. It is checking for them in the current directory. If you check out
> another copy someplace, I think you'll find that the cvs update *does* work as
> expected and that the real problem is your checked out copy has some .# state
> that is missing. How it got rm'd I can only guess.

I fix it by:

cd /sys/isofs/cd9660
mv cd9660_vnops.c cd9660_vnops.c.bozo
cvs update cd9660_vnops.c		[ complains file was lost ]
rm cd9660_vnops.c
mv cd9660_vnops.c.bozo cd9660_vnops.c


Next time there is a mod to the file on Freefall that gets pulled down
via SUP, I will have the same problem.

The file is checked out.

I have not done any checkins to get lost when I SUP.

Rechecking out the file fixes the problem.

After I recheckout the file, my CVSROOT/history file contains the line:

U30c63b5d|terry|/b/cvstree/usr.*0|src/sys/isofs/cd9660|1.23|cd9660_vnops.c

If I manually remove this line, the problem will recurr.

Clearly, the problem is that the history file (which comes down with the
SUP!) for my local checkouts vs. the files I have modified does not match
for the rev I have checked out.

Would you agree?


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.