FYI: cvs can break a checked out working directory.

[Bulgrien, Kevin]

Reference:

  cvs-1.11.19-6mdk

Disclaimer:

  * This is not the latest revision.  A Mandriva Corporate Server 4.0
    distribution is in use and this is the stock build included with it.

  * Use of arcanery like cvs admin -o is a recognized hazard, and a certain
    signal to be more careful than normal.  The following is demonstrated
    using cvs admin -o which is understood to be "not recommended", and this
    is known.  This post is also understood to document an issue that may be
    seen to contribute to the reason cvs admin's use is not recommended.

Issue

The following is an example of cvs admin -o breaking a working directory.

In the following example, the working directory appears to be 1.2. 
CVS diff shows no differences to the last revision still in CVS.

To avoid the breakage, `cvs update` MUST be run after cvs admin -o
to deleting revisions presently in the working directory, but this
step is omitted to simulate what happens if a developer forgets to
update.

# This example was reconstructed from a test repository, but did
# happen in "real life", and was simply reproduced in this manner.
# Here we confirm the state of the sandbox, and execute the monster
# that is cvs admin -o.  Why cvs admin -o?  Perhaps Mr. Developer
# was afflicted by any number of issues.  He _really_ does not want
# anyone to see his latest commit, but due to one of many possible
# human conditions, did the commit in the heat of something.

$ cvs status file.txt
===================================================================
File: file.txt          Status: Up-to-date

   Working revision:    1.2     Mon Jan 14 17:39:51 2008
   Repository revision: 1.2     /home/username/cvs/rep/file.txt,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)
$ cvs admin -o 1.2 file.txt
RCS file: /home/username/cvs/rep/file.txt,v
deleting revision 1.2
done

# Our developer could immediately follow cvs admin -o with cvs status
# to get a reminder that all is not yet well with the repository, but
# this is not a usual step, and can be forgotten, especially if in a
# state that might have caused him to use cvs admin -o in the first
# place.

$ cvs status file.txt
===================================================================
File: file.txt          Status: Needs Patch

   Working revision:    1.2     Mon Jan 14 17:39:51 2008
   Repository revision: 1.1     /home/username/cvs/rep/file.txt,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)
$

# Other cvs commands give no hint of the lurking danger.  Now this is
# an odd one.  The file in the sandbox most certainly is different
# from what is in the repository.

$ cvs diff
cvs diff: Diffing .
cvs diff: Diffing CVSROOT
$

# The repository does not contain the deleted revision.

$ grep 1.2 ../rep/file.txt,v
$

# Our developer proceeds to edit away what he was so reluctant to have
# seen.  The file which should be updated first, is instead edited.

$ echo "New edit." >>file.txt
$

# The working directory is now broken.  The author did not find a cvs
# command that would fix it at this stage.  Perhaps one lies yet
# undiscovered.

$ cvs diff
cvs diff: Diffing .
cvs [diff aborted]: could not find desired version 1.2 in
/home/username/cvs/rep/file.txt,v
$ cvs update
cvs update: Updating .
cvs [update aborted]: could not find desired version 1.2 in
/home/username/cvs/rep/file.txt,v
$

# At this point, even reverting the file manually to 1.1 by hand will not
# change the result.  Nor will forced updates.

$ cvs update -fC filel.txt
cvs [update aborted]: could not find desired version 1.2 in
/home/username/cvs/rep/file.txt,v
$ cvs update -fC -r 1.1 file.txt
cvs [update aborted]: could not find desired version 1.2 in
/home/username/cvs/rep/file.txt,v
$

# This is an example of fixing a working directory broken by cvs admin -o
# After this error occurs, the sandbox is awkward to correct.  At the time
# of this writing, the only correction known to the author is to manually
# edit the CVS/Entries file to change the deleted revision number of
# file.txt to the last good revision, and then cvs update. 

$ grep file.txt CVS/Entries
/file.txt/1.2/Mon Jan 14 17:39:51 2008//
$ sed -e 's-file.txt/1.2/-file.txt/1.1/-' CVS/Entries >CVS/Entries.new
$ grep file.txt CVS/Entries.new
/file.txt/1.1/Mon Jan 14 17:39:51 2008//
$ mv CVS/Entries.new CVS/Entries
mv: overwrite `CVS/Entries'? y
$ cvs update
cvs update: Updating .
M file.txt
cvs update: Updating CVSROOT
$

The working directory is now back to normal.

Realizing that this is yet another reason not to use cvs admin -o, the
situation still seems unfortunate, as one might think it reasonable to
assume that manual edit of CVS/Entries, or re-checkout of the working
directory, is not an ideal way to correct this botched CVS/Entries file.

--- 
Kevin R. Bulgrien

This email message is for the sole use of the intended recipient(s) and may 
contain General Dynamics SATCOM Technologies confidential or privileged 
information.  Any unauthorized review, use, disclosure or distribution is 
prohibited.  If you are not an intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.