From owner-freebsd-current Wed Dec 6 19:08:40 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA25946 for current-outgoing; Wed, 6 Dec 1995 19:08:40 -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 TAA25937 for ; Wed, 6 Dec 1995 19:08:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA03508; Wed, 6 Dec 1995 20:03:50 -0700 From: Terry Lambert Message-Id: <199512070303.UAA03508@phaeton.artisoft.com> Subject: Re: changes in -current..TEST please To: julian@ref.tfs.com (Julian Elischer) Date: Wed, 6 Dec 1995 20:03:49 -0700 (MST) Cc: terry@lambert.org, davidg@root.com, gibbs@freefall.freebsd.org, phk@critter.tfs.com, imb@scgt.oz.au, current@FreeBSD.org In-Reply-To: <199512070235.SAA13072@ref.tfs.com> from "Julian Elischer" at Dec 6, 95 06:35:07 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 found that I had to add a group 'ncvs' to my groups file > that matched the one on freefall, and then I had to make myself a member , > log out and log in again.. once that was done, it worked like a charm > trouble was that I didn't have permissions to do all I wanted to do, > and SUP kep changing the files back the way it wanted them.. > this solved the problem... OK. I did this, and no dice. Didn't help. I *have* found out exactly what my problem is, however. I saved off a "damaged" directory and experimented on it and compared it to the original to see *exactly* what "naughty bits" changed. Ugh. My checked out tree's CVS/Entries file entry for the file it is complaining about matches the revision tag on the file I checked out an not on the one in the actual CVS tree: /vfs_init.c/1.13/Thu Dec 7 02:37:53 1995// If I manually edit the CVS/Entries file so that the revision matches the one in the SUP'ed CVS tree, then the problem disappears: /vfs_init.c/1.18/Thu Dec 7 02:37:53 1995// This is basically what happens if I: mv vfs_init.c vfs_init.good cvs update vfs_init.c [ "file was lost" ] mv vfs_init.good vfs_init.c If I manually edit the CVS/Entries file and add a tag for the revision already in the file, then the problem goes away as well: /vfs_init.c/1.13/Thu Dec 7 02:37:53 1995//T1.13 What it looks like is that my checkout should specify the current revision for my revision tag, so that the tags will be there, or there needs to be an option to cvs update to make it indifferent to the Entries revision mismatch that will occur every time that someone updates a file on FreeFall. You may not personally see this if you checkin mods on Freefall, sup a new CVS tree, then recheckout your tree, since you will be throwing away your local Entries file. It seems that the problem only occurs when the file has been modified since the checkout: the date is irrelevant (I've tested), but the fact that it would have put up an "M" if it was working right is enough to puke it out. There doesn't seem to be an option for this. I thought that "-r HEAD" would translate into a "//T1.13" if the rev was 1.13 (seems like HEAD would be a stupid sticky tag otherwise) but no dice. It makes a "//THEAD" entry, which is, as far as I can see, probably the most useless thing on the planet. 8-|. Am I doomed to manually revising the Entries file to update it so that cvs update doesn't puke? The funny thing is, update seems to be the only one that cares... diff and others work correctly. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.