Re: Problem with cvs update -r... -D...

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Summary: Renny's problem still exists in top-of-tree CVS.

Basic problem:

When adding a new file to a branch where there is no file named the same
on the trunk, a version 1.1 is created which is dead before the new file
is given a 1.1.2.1 version and put into the Attic.

When adding a new file to a branch where there is a trunk version of the
file, the new version is branched from the top-of-tree parent version.
This implies that the time between the creation of the mainline branch
point and the time at which the first branch version is committed will
appear to have the trunk version visible in the branch.

This problem still exists in cvs 1.11.17.1 and cvs 1.11.9.1 top-of-tree
stable and feature branches for the CVS from cvshome.org.

A way to work around this problem would be to create a dead version of
the file added to the branch which has the same timestamp as the trunk
version of the file. That is

  Current situation

        1.n      - trunk version of the file.
        1.n.0.m  - magic tag assigned for the new branch
        1.n.m.1  - the newly added version of the file.

  Proposed fix

        1.n      - trunk version of the file.
        1.n.0.m  - magic tag assigned for the new branch
        1.n.m.1  - a dead version with the 1.n timestamp
        1.n.m.2  - the newly added version of the file.

How to reproduce

                --------------- cut here ---------------
    #!/bin/sh -x
    # Time  Rev     Branch  Comments
    # T0            trunk   first-dir created
    # T1    1.1     trunk   first-dir/file1 committed "trunk-1"
    #               br2     branch created
    # T2    1.2     trunk   first-dir/file1 committed "trunk-2"
    # T3    1.1.2.1 br2     first-dir/file1 committed "br2-1"
    # T4    1.1     trunk   first-dir/file3 dead
    # T4    1.1.2.1 br2     first-dir/file3 committed "br2-1"
    # T5    1.1     trunk   first-dir/file2 committed "trunk-1"
    #
    # FIXCVS? PROBLEM... checkouts of the br2 branch after T6
    # which specifies a timestamp between T5 and before T6 will
    # show version 1.1 of the file on the br branch even though
    # that was not the real branch point chosen by the user.
    #
    # T6    1.1.2.1 br2     first-dir/file2 committed "br2-1"

    rm -fr /tmp/cvs-testit top
    CVSROOT=/tmp/cvs-testit; export CVSROOT
    TZ=UTC; export TZ
    cvs init
    cvs co -d top -l .
    cd top
    mkdir first-dir
    cvs add first-dir                   # Time T0
    cd first-dir                        # Time T0
    echo trunk-1 >file1                 # Time T0
    cvs add file1                       # Time T0
    cvs ci -m add file1                 # Time T1
    cvs tag -b br2 file1                # Time T1 br2 created
    echo trunk-2 >file1                 # Time T1
    cvs ci -m trunk-modify file1        # Time T2
    cvs up -r br2                       # Time T2
    echo br2-1 >file1                   # Time T2
    cvs ci -m br-modify file1           # Time T3
    echo br2-1 >file3                   # Time T3
    cvs add file3                       # Time T3
    cvs ci -m newfile file3             # Time T4, file3 v1.1 is dead
    cvs up -A                           # Time T4
    echo trunk-1 >file2                 # Time T4
    cvs add file2                       # Time T4
    cvs ci -m newfile file2             # Time T5
    cvs up -r br2                       # Time T5
    echo br2-1 >file2                   # Time T5
    cvs add file2                       # Time T5
    cvs ci -m newfile file2             # Time T6

    getrlogdate () {
        while read token day time value; do
            case $token in
            date:) value=`echo "$day $time" | sed "s,;.*,,"`
                   echo "$value UTC"
                   break
                   ;;
            esac
         done
    }
    
    T5=`cvs rlog -N -r1.1 first-dir/file2 | getrlogdate`
    cvs up -r br2 -D"$T5"
    echo "trunk-1" | cmp - file2 && echo 'bug? file2 version 1.1 found on br2'
                --------------- cut here ---------------

I will add some additional tests to the tagdate testcase in sanity.sh
with a FIXCVS comment in it, but I don't have time to write a patch to
add.c for this problem right now. If anyone else wants to submit a
patch, I'll see what I can do about getting it installed.

        Thanks,
        -- Mark

Renny Barrett <rbarrett@curamsoftware.com> writes:

> Dear CVS experts,
> 
>  
> 
> I'm running into a problem running cvs update with BOTH the options -r
> <branch name> and -D <date>.  At best the behaviour I'm seeing is
> unintuitive (at least to me!) and at worst I've uncovered a bug.  I'd
> greatly appreciate any thoughts or comments you might have or any light you
> can shed on the matter.
> 
>  
> 
> Here's a description of how to recreate the behaviour I'm seeing, together
> with comments on what I'm trying to achieve.
> 
>  
> 
> Let's say that I have a (large) code base, and one day I release my product
> to a customer.  Recognising that I may have to supply patches to the
> customer whilst also working on the next version, I create a "Patch" branch:
> 
>  
> 
> cvs rtag -b Patch <MyModule>
> 
>  
> 
> At some stage later, a developer working on the HEAD creates and commits a
> new file:
> 
> cvs update -A
> 
> cvs add new.txt
> 
> cvs commit new.txt
> 
>  
> 
> At some stage later again, a developer working on the Patch branch creates
> and commits a new files which has the same name and location as that created
> above:
> 
> cvs update -r Patch
> 
> cvs add new.txt
> 
> cvs commit new.txt
> 
>  
> 
> So there are 3 time periods in the history of new.txt which I'll refer to
> below:
> 
> -          TP1 - the time up until new.txt was committed to the HEAD (i.e.
> during TP1 new.txt existed neither on the HEAD nor the Patch branch)
> 
> -          TP2 - the time from when new.txt was committed to the HEAD but
> before it was committed to the Patch branch (i.e. during TP2 new.txt existed
> on the HEAD but not on the Patch branch)
> 
> -          TP3 - the time from when new.txt was committed to the Patch
> branch (i.e. during TP3 new.txt existed both on the HEAD and the Patch
> branch, possibly with different contents).
> 
>  
> 
> Now, a developer requires a new branch off the Patch branch as it was during
> a particular time (T) during TP2.  Had we tagged the files on the Patch
> branch at T then all would be fine and dandy - we'd simply create a new
> branch based on this tag.  However, we neglected to create such a tag so we
> need to download the contents of our Patch branch as it was at time T and
> then we can use cvs tag to tag these downloaded versions and away we go.
> 
>  
> 
> To get the contents of the Patch branch as it was at time T, I'm attempting
> to use 
> 
> cvs update -r Patch -D<T>
> 
> .which is where I'm running into problems.  Before I describe what I'm
> seeing, I'll explain some other commands which I've tried which do seem to
> work the way I'd expect:
> 
>  
> 
> -          cvs update -D <a time during TP1> - file is deleted from local
> directory ("new.txt is no longer in the repository") - this is correct as
> the file didn't exist on the HEAD during TP1
> 
> -          cvs update -D <T, which is during TP2> - I get the file which was
> committed to the HEAD, which is correct
> 
> -          cvs update -D < a time during TP3>  - I get the file which was
> committed to the HEAD, which is correct
> 
>  
> 
> -          cvs update -r Patch -D <a time during TP1> - file is deleted from
> local directory ("new.txt is no longer in the repository") - this is correct
> as the file didn't exist on the Patch branch during TP1
> 
> -          cvs update -r Patch -D <a time during TP3> - I get the file which
> was committed to the Patch branch, which is correct
> 
>  
> 
> and finally, the problem one:
> 
>  
> 
> -          cvs update -r Patch -D <T, which is during TP2> - I EXPECT to
> have the local file deleted ("new.txt is no longer in the repository"),
> because at time T new.txt did not exist on the Patch branch - what I
> ACTUALLY get is the version of new.txt which existed on the HEAD at time T.
> 
>  
> 
> Thus I don't seem to be able to reliably recreate the contents of Patch at
> time T - well, not using cvs update -r. -D. anyway - is there some other
> command or option combination that I should use?  I see that cvs update has
> a "-f" option which forces a HEAD revision match if the rag/date isn't found
> - it's almost as if -f option is kicking in without me specifying it.
> 
>  
> 
> We're using CVS 1.11.1.1 on Windows talking to a Linux server using
> :pserver:; however, I can recreate the same problem on my Windows machine
> with  cvs 1.12.9 using :local:.
> 
>  
> 
> Any help or observations will be gratefully received!
> 
>  
> 
> Many thanks,
> 
>  
> 
> Renny Barrett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBfNPN3x41pRYZE/gRAtCAAJ9k2xbqNOiyFwS+s0LcXL9L5NxTaACguCpq
DgEGAk/G5ODl1Biz0IZN130=
=08l8
-----END PGP SIGNATURE-----