bin/42961: cvs near-silently throws away local mods

[dholland%eecs.harvard.edu@localhost]

>Number:         42961
>Category:       bin
>Synopsis:       cvs near-silently throws away local mods
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 11 19:15:00 +0000 2010
>Originator:     David A. Holland
>Release:        NetBSD 4.99.72 (20081004)
>Organization:
>Environment:
System: NetBSD valkyrie 4.99.72 NetBSD 4.99.72 (VALKYRIE) #32: Sat Oct 4 
12:25:22 EDT 2008 root@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

I had a largish patch to ufs_wapbl.c in my "miscellaneous" HEAD source
tree (not one of the important patches fortunately, it was a pile of
comments documenting the refcount flow in rename) and on cvs update
just now the following happened:

   valkyrie% cvs -q update -dP
   P lfs/lfs_vfsops.c
   P ufs/ufs_lookup.c
   P ufs/ufs_wapbl.c
   cvs update: checksum failure after patch to ufs/ufs_wapbl.c; will refetch
   cvs client: refetching unpatchable files
   cvs update: warning: ufs/ufs_wapbl.c was lost
   U ufs/ufs_wapbl.c
   valkyrie% 

and now:
   valkyrie% cvs diff ufs/ufs_wapbl.c
   valkyrie% 

Note that it did not even attempt to merge.

It also did not generate a .#ufs_wapbl.c.1.7 file containing the prior
modified version. (I do have a .#ufs_wapbl.c.1.6 file from the
previous merge some time back, but if the changes had been more recent
I wouldn't have.)

I have seen this problem twice before in recent months (the checksum
failure message) but this is the first time it happened someplace I
knew for sure what was there beforehand.

The tree where this happened is updated regularly. Note also that
while this machine's install is outdated it is as far as I know the
same cvs as in -5.

This is a pretty serious problem, as I and a lot of people keep random
uncommitted/local changes in source trees and rely on CVS not to
randomly lose them like this.

Worse, in a large update most likely the message would go by without
anyone noticing it; I tend to grep update logs for '^[CM]' and some
people just do find . -name '*.rej' to see if anything failed.

>How-To-Repeat:

I have no idea what might trigger this.

>Fix:

Shoot CVS?