76855 - cvs bug checks out deleted files into local copies and corrupts builds

Status: VERIFIED DUPLICATE of bug 76856

(mozilla.org Graveyard :: Server Operations, task)

Description

[Bruce Tiffany]

A bug has been identified in CVS v1.11 that affects mozilla's cvs servers.  If 
you use checkout -D <now> SeaMonkeyAll you get ~39 more files than if you use 
checkout SeaMonkeyAll.  Some of these are duplicate header files that break 
tinderboxes (os/2).  Suggest that all of these be cvs -removed (again) and all 
tinderbox maintainers be advised to use checkout -D (a.k.a. moz_co_date 
argument to client.mk) to detect "recreated" files as soon as they happen.  
This actually broke os/2 about 4 weeks ago but we didn't unlayer it until 
now.   Attached is an excerpt from the CVS discussion group explaining the 
problem. 

On Thu, Apr 19, 2001 at 03:11:46PM -0500, Bruce Tiffany wrote:
> I believe I've found the source of my confusion.  When a file is deleted
> in
> CVS, then revised by another user, cvs checkout will not produce the file,
> however cvs checkout -D <now> will.  I'm uncertain if that's a bug or a
> feature, use of checkout -D ... seems to be the safer way to go.

Looks like a bug to me.  Tested with CVS 1.11, all actions
performed on the trunk:

> Time   User 1                        User 2
> ----   --------------------          ------------------------------
>
>   |    cvs checkout proj1            cvs checkout proj1
>   |    rm foo
>   |    cvs -remove foo
>  \|/   cvs commit

Does what you'd expect -- checks in a "dead" revision and moves
the ,v file to the attic.

>                                      edit foo

Note that a "cvs commit" here correctly reports "Up-to-date check
failed for `foo'".

>                                      cvs update

Says:
	$ cvs update
	cvs update: Updating .
	RCS file: /home/erics/t2/Repos/p/Attic/foo,v
	retrieving revision 1.1
	retrieving revision 1.2
	Merging differences between 1.1 and 1.2 into foo
	foo already contains the differences between 1.1 and 1.2
	$

Shouldn't it have reported a conflict?

>                                      cvs commit

Commits User 2's text as a new undead revision (ie. state="Exp"),
but DOES NOT move the ,v file back out of the Attic, thus
violating this constraint, as documented in the manual, node
"Attic":
	[...] the rule is that the RCS file is stored in the
	attic if and only if the head revision on the trunk has
	state `dead'.

The reported inconsistency between "cvs checkout" and
"cvs checkout -D now" follows from this.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        [e-mail]
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
	- RFC 1925 (quoting an unnamed source)

_______________________________________________
Info-cvs mailing list
[e-mail]
http://mail.gnu.org/mailman/listinfo/info-cvs

Comment 1

[cls]

*** This bug has been marked as a duplicate of 76856 ***

Comment 2

[timeless]

vrfy dupe