FYI: CVS can create tags on "future" revisions.

[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 example demonstrates how use of cvs admin -o can cause a tag
to
point to a different file revision than was intended by the tagger.  The tag
will point to a revision of the file "NOT YET COMMITTED".  In this example,
FUTURE_TAG ends up pointing to revision 1.2 instead of the intended 1.1.

# A test repository has been setup and an initial file has been
# committed.  This did happen in real life, but this example has
# been manufactured to reproduce it.
 
$ 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
$

# Note that if the developer does CVS status, cvs attempts to say
# that the sandbox needs updating, but for purposes of the example
# the developer forgets that the sandbox needs updating after use
# of cvs admin -o on a revision of a file in the sandbox.

$ 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)
$

# The author feels that CVS should have balked on the following
# command, but realizes that use of cvs admin -o (not recommended)
# is the root problem.

$ cvs tag FUTURE_TAG file.txt
T file.txt

# A non-existant revision (1.2) is now tagged.

$ cvs update -r FUTURE_TAG
cvs [update aborted]: no such tag FUTURE_TAG

# We can see why:

$ grep file.txt CVS/Entries
/file.txt/1.2/Mon Jan 14 17:53:47 2008//

# The following is a bit of a hack, but is necessary at least in
# some cases.  Various tests were made under different circumstances
# where many cvs commands failed to update the CVS/Entries file.
# This is not to say sometimes it cannot be fixed "properly".

$ echo -e "/file.txt\/\ns/1.2/1.1/\nwq" | ed -s CVS/Entries
 
/file.txt/1.2/Mon Jan 14 17:53:47 2008//
$ grep file.txt CVS/Entries
/file.txt/1.1/Mon Jan 14 17:53:47 2008//

# After fixing the CVS/Entries file, now clean up the sandbox to
# remove the deleted revision.

$ cvs update -f
cvs update: Updating .
M file.txt
cvs update: Updating CVSROOT

# Overwrite the deleted local copy with the current cvs revision

$ cvs update -fC -r 1.1 file.txt
(Locally modified file.txt moved to .#file.txt.1.1)
U file.txt
$ cvs update -A

# Now, create the future revision that was tagged above.

$ echo "Untagged revision 1.2" >>file.txt
$ cvs commit -m "commit 1.2" file.txt
 Checking in file.txt;
 /home/username/cvs/rep/file.txt,v  <--  file.txt
 new revision: 1.2; previous revision: 1.1
 done

# And here it is in all its ignominious glory.

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

   Working revision:    1.2     Mon Jan 14 18:55:37 2008
   Repository revision: 1.2     /home/username/cvs/rep/file.txt,v
   Sticky Tag:          FUTURE_TAG (revision: 1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

The point?

CVS admin -o can get you more ways than one, but, cvs also does not
always do what you might think.  It should have been able to tell
that the "tagged" revision did not exist, but declined to check
to see if it did before applying the tag.  It trusted a CVS/Entries
file which was not updated by the cvs admin -o command.

What if anything should be done about that?  I don't know, but this
and other situations show that CVS doesn't use the ,v file header
and revision log to maximum advantage.

--- 
Kevin R. Bulgrien

If there is a brain-dead footer here, I didn't place it as I this is
knowingly posted to a public forum.

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.