Re: [Issue 97] - RCS_getdate vendor branch bug

[Mark D. Baushke]

dprice@cvshome.org writes:
> Please include a test case demonstrating the bug and another
> demonstrating that the patch fixes the problem.

I believe the rcs4 test case included after my .signature will
demonstrate the problem on an unpatched cvs executable and will pass for
cvs executables that have been patched.

As for the second part of this case. The following rcs commands will
create a file1,v file that has a version 1.1 that is at least one second
away from version 1.1.1.1 as exists in some older cvs repositories.
The subsequent commit of a new local version and a cvs update to get
at yesterdays version will show the error:

    /bin/rm -fr /tmp/cvs-sanity
    mkdir -p /tmp/cvs-sanity
    cvs -d /tmp/cvs-sanity/cvsroot init
    mkdir -p /tmp/cvs-sanity/cvsroot/rcs5-dir
    cd /tmp/cvs-sanity/cvsroot/rcs5-dir
    echo 'test1' > file1
    echo 'Initial revision'| ci -t- -d'2000-12-01 01:23:34+00' -u file1
    ci -f -r1.1.1.1 -m'add' -d'2000-12-01 01:23:35+00' -u file1
    rcs -b1.1.1 file1,v
    rcs -nopenmunger:1.1.1 file1
    rcs -nopenmunger-1_0:1.1.1.1 file1
    cd /tmp/cvs-sanity
    cvs -d /tmp/cvs-sanity/cvsroot co rcs5-dir
    cd rcs5-dir
    echo 'another line' >>file1
    cvs ci -m one-line file1
    cvs -d /tmp/cvs-sanity/cvsroot up -D "yesterday"

You will notice that version 1.1 is checked out of file1 rather than
version 1.1.1.1. There do exist some cvs repositories that were created
a long time ago and for which there is between one and two seconds
between version 1.1 and version 1.1.1.1 even though they were created at
the same time by a cvs import.

I have not tried to arrive at a patch that deals with such a 1.1.1.1
version as being 'close enough' to a version 1.1 that it should use
version 1.1.1.1, but if you think it desirable, please do fix that
problem as well.

ChangeLog entry:

* 2003-02-07  Mark D Baushke <mdb@cvshome.org>

        * rcs.c (RCS_getdate): Fix a bug that shows up when checking out
        files by date with the "-D date" command line option. There is
        code in the original to handle a special case. If the date search
        finds revision 1.1 it is supposed to check whether revision
        1.1.1.1 has the same date stamp, which would indicate that the
        file was originally brought in with "cvs import". In that case it
        is supposed to return the vendor branch version 1.1.1.1.

        However, there is a bug in the code. It actually compares the date
        of revision 1.1 for equality with the date given on the command
        line -- clearly wrong. This commit fixes the coding bug.

        Note: There is an additional bug which is _not_ fixed in this
        commit. The date comparison should not be a strict equality test.
        It should allow a fudge factor of, say, 2-3 seconds. Old versions
        of CVS created the two revisions with two separate invocations of
        the RCS "ci" command. We have many old files in the tree in which
        the dates of revisions 1.1 and 1.1.1.1 differ by 1 second.

        This bug was discovered and fixed for FreeBSD cvs. See v 1.21 of
        http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/cvs/src/rcs.c.diff
        for more information. 

Index: src/rcs.c
===================================================================
RCS file: /cvs/ccvs/src/rcs.c,v
retrieving revision 1.265
diff -u -p -r1.265 rcs.c
--- rcs.c       7 Feb 2003 19:53:30 -0000       1.265
+++ rcs.c       7 Feb 2003 23:08:24 -0000
@@ -2999,8 +2999,10 @@ RCS_getdate (rcs, date, force_tag_match)
        p = findnode (rcs->versions, "1.1.1.1");
        if (p)
        {
+           char *date_1_1 = vers->date;
+
            vers = (RCSVers *) p->data;
-           if (RCS_datecmp (vers->date, date) != 0)
+           if (RCS_datecmp (vers->date, date_1_1) != 0)
                return xstrdup ("1.1");
        }
     }
Index: src/sanity.sh
===================================================================
RCS file: /cvs/ccvs/src/sanity.sh,v
retrieving revision 1.755
diff -u -p -r1.755 sanity.sh
--- sanity.sh   7 Feb 2003 21:34:03 -0000       1.755
+++ sanity.sh   7 Feb 2003 23:29:57 -0000
@@ -17357,6 +17357,95 @@ EOF
          rm -rf ${CVSROOT_DIRNAME}/first-dir
          ;;
 
+       rcs4)
+         # Fix a bug that shows up when checking out files by date with the
+         # "-D date" command line option.  There is code in the original to
+         # handle a special case.  If the date search finds revision 1.1 it
+         # is supposed to check whether revision 1.1.1.1 has the same date
+         # stamp, which would indicate that the file was originally brought
+         # in with "cvs import".  In that case it is supposed to return the
+         # vendor branch version 1.1.1.1.
+         # 
+         # However, there is a bug in the code. It actually compares
+         # the date of revision 1.1 for equality with the date given
+         # on the command line -- clearly wrong. This commit fixes
+         # the coding bug.
+         # 
+         # There is an additional bug which is _not_ fixed yet. 
+         # The date comparison should not be a strict
+         # equality test. It should allow a fudge factor of, say, 2-3
+         # seconds. Old versions of CVS created the two revisions
+         # with two separate invocations of the RCS "ci" command. We
+         # have many old files in the tree in which the dates of
+         # revisions 1.1 and 1.1.1.1 differ by 1 second.
+
+          mkdir rcs4
+          cd rcs4
+
+         mkdir imp-dir
+         cd imp-dir
+         echo 'OpenMunger sources' >file1
+
+         # choose a time in the past to demonstrate the problem
+         TZ=GMT touch -t 200012010123 file1
+
+         dotest_sort rcs4-1 \
+"${testcvs} import -d -m add rcs4-dir openmunger openmunger-1_0" \
+'
+
+N rcs4-dir/file1
+No conflicts created by this import'
+         echo 'OpenMunger sources release 1.1 extras' >>file1
+         TZ=GMT touch -t 200112011234 file1
+         dotest_sort rcs4-2 \
+"${testcvs} import -d -m add rcs4-dir openmunger openmunger-1_1" \
+'
+
+No conflicts created by this import
+U rcs4-dir/file1'
+         cd ..
+         # Next checkout the new module
+         dotest rcs4-3 \
+"${testcvs} -q co rcs4-dir" \
+'U rcs4-dir/file1'
+         cd rcs4-dir
+         echo 'local change' >> file1
+
+         # commit a local change
+         dotest rcs4-4 \
+"${testcvs} -q commit -m hack file1" \
+"Checking in file1;
+${CVSROOT_DIRNAME}/rcs4-dir/file1,v  <--  file1
+new revision: 1\.2; previous revision: 1\.1
+done"
+         # now see if we get version 1.1 or 1.1.1.1 when we ask for
+         # a checkout by time... it really should be 1.1.1.1 as
+          # that was indeed the version that was visible at the target
+         # time.
+         dotest rcs4-5 \
+"${testcvs} -q update -D 'October 1, 2001' file1" \
+'U file1'
+         dotest rcs4-6 \
+"${testcvs} -q status file1" \
+'===================================================================
+File: file1                    Status: Up-to-date
+
+   Working revision:   1\.1\.1\.1      .*
+   Repository revision:        1\.1\.1\.1      
'${CVSROOT_DIRNAME}'/rcs4-dir/file1,v
+   Sticky Tag:         (none)
+   Sticky Date:                2001\.10\.01\.07\.00\.00
+   Sticky Options:     (none)'
+
+         if $keep; then
+           echo Keeping ${TESTDIR} and exiting due to --keep
+           exit 0
+         fi
+
+         cd ../..
+          rm -r rcs4
+          rm -rf ${CVSROOT_DIRNAME}/rcs4-dir
+         ;;
+
        lockfiles)
          # Tests of CVS lock files.
          # TODO-maybe: Add a test where we arrange for a loginfo