Subject: Re: cvs 1.11.10 will be imported
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Frederick Bruckman <fredb@immanent.net>
List: tech-userlevel
Date: 12/11/2003 15:50:00
On Thu, 11 Dec 2003, Bill Studenmund wrote:

> On Thu, Dec 11, 2003 at 11:27:45AM -0600, Frederick Bruckman wrote:
> > On Thu, 11 Dec 2003, Bill Studenmund wrote:
> >
> > Well, this is what I get today, on my own little repository:
> >
> >     # cvs update -A
> >     cvs server: Updating .
> >     cvs server: conflict: foo.c is modified but no longer in the repository
> >     C foo.c
>
> You didn't resolve the conflicts.
>
> >     # cvs commit -m'Try to commit anyway.'
> >     cvs commit: Examining .
> >     cvs server: Up-to-date check failed for `foo.c'
> >     cvs [server aborted]: correct above errors first!
>
> You have unresolved conflicts, I think cvs ci is supposed to complain. :-)
>
> >     # cvs version
> >     Client: Concurrent Versions System (CVS) 1.11.5 (client/server)
> >     Server: Concurrent Versions System (CVS) 1.11.5 (client/server)
> >
> > I get the same result if I try to commit from a backed-up directory
> > which never got a "cvs update". Maybe the CVS folks do fix bugs, after
> > all. ;-)
>
> Try fixing the conflicts.

Not easy. "cvs add" balks. I had to move it out of the way first:

    # cvs update -A
    cvs server: Updating .
    cvs server: conflict: foo.c is modified but no longer in the repository
    C foo.c
    # cvs add foo.c
    cvs server: foo.c already exists, with version number 1.1.1.1
    # cvs update -A
    cvs server: Updating .
    cvs server: conflict: foo.c is modified but no longer in the repository
    C foo.c
    # mv foo.c foo.c.bak
    # cvs update -A
    cvs server: Updating .
    cvs server: warning: foo.c is not (any longer) pertinent
    # mv foo.c.bak foo.c
    # cvs status foo.c
    cvs server: use `cvs add' to create an entry for foo.c
    ===================================================================
    File: foo.c             Status: Unknown

       Working revision:    No entry for foo.c
       Repository revision: 1.2     /cvsroot/test/Attic/foo.c,v

    # cvs add foo.c
    cvs server: re-adding file foo.c (in place of dead revision 1.2)
    cvs server: use 'cvs commit' to add this file permanently
    # cvs status foo.c
    ===================================================================
    File: foo.c             Status: Locally Added

       Working revision:    New file!
       Repository revision: 1.2     /cvsroot/test/Attic/foo.c,v
       Sticky Tag:          (none)
       Sticky Date:         (none)
       Sticky Options:      (none)

    # cvs update foo.c
    A foo.c
    # cvs commit -m"Back again?"
    Checking in foo.c;
    /cvsroot/test/foo.c,v  <--  foo.c
    new revision: 1.3; previous revision: 1.2
    done
    # cvs status foo.c
    ===================================================================
    File: foo.c             Status: Up-to-date

       Working revision:    1.3
       Repository revision: 1.3     /cvsroot/test/foo.c,v
       Sticky Tag:          (none)
       Sticky Date:         (none)
       Sticky Options:      -ko

...which didn't leave it in The Attic. (For the test, I imported with
"-ko", as I often do.)

> Also, the bug report is:
>
> http://ccvs.cvshome.org/servlets/ReadMsg?msgId=13231&listName=bug

The scenario you painted in that message isn't exactly the same as the
one you gave in this thread. In that case, you knew the file was dead,
and tried to revive it with "cvs update -rsomething file.c; cvs add
file.c". When I try that with 1.11.5...

    # cvs add foo.c
    cvs server: foo.c already exists, with version number 1.3

Changing the file followed by "cvs update -A" (as in your report)
gives the conflict as above, so the bug really is fixed in 1.11.5
(sort of -- at least at doesn't let me commit to The Attic).

I believe the right way to revivie a known dead file has always been
to use something like "cvs update -jHEAD -jsomething foo.c". In
1.11.5, that changes the status to "New file!" -- no explicit "cvs
add" required -- and a subsequent commit seems to do the right thing.

Frederick