undesirable cvs behavior?

[Gregory N. Olszewski]

Hello. I'm writing regarding the behavior of cvs on the
backuprecover-15 test case. The comments call it a 'failure case',
which seems to mean 'the behavior is broken, but since we know what
the behavior is, we'll make sure we don't change it accidently'. 

# Note that backuprecover-15 is probably a failure case
#   If nobody else had a more recent update, the data would be lost
#     permanently
#   Granted, the developer should have been notified not to do this
#     by now, but still...

We have a situation where we may have to quickly failover to a mirror
which may be missing 5-10 minutes of data. In that case, it would be
impractical to ensure that every engineer knows that they may lose data
if they update. Consequently, I've written the attached patch to
treat a workspace with a newer unmodified version of a file as an
error. 

The test suite needs a few changes to pass; With the patch, cvs
behavior in response to an admin command changes. Currently, if
version 1.5 is removed via 'cvs admin -o', any tree with an unmodified
version of 1.5 silently reverts to 1.4 at the time of next
update. After the patch, cvs will complain at the time of next
update. Consequently, a few tests which check the previous behavior
need changes.  

I have a few questions:

1. Does anyone see any problems that this patch would cause?

2. Would cvs developers be interested in integrating this behavior?

If so, I'll be happy to generate a real patch (ChangeLog entry,
testsuite changes, GNU coding style, copyright assignment (if
needed)), but I wanted to check for interest before I go through and
do all the details.

3. Does anyone know of a better way to accomplish this?

Thanks for your time,

greg

-- 
address@hidden | maintaining individual accountability
      http://docs.yahoo.com/info/values/

cvs.unknownrevision.diff
Description: Text document