Subject: Re: cvs 1.11.10 will be imported
To: Bill Studenmund <>
From: Frederick Bruckman <>
List: tech-userlevel
Date: 12/11/2003 11:27:45
On Thu, 11 Dec 2003, Bill Studenmund wrote:

> On Thu, Dec 11, 2003 at 08:04:01AM -0600, Frederick Bruckman wrote:
> > On Wed, 10 Dec 2003, Bill Studenmund wrote:
> >
> > > You have a file with local changes. Someone deletes the file from cvs,
> > > putting the ,v file in the Attic. You cvs update, then you check in your
> > > changes. You bring the file back to life, but the ,v file stays in the
> > > Attic. So future checkouts won't pick it up unless you mention it by name.
> >
> > Ah... that explains a lot. I have pulled files out of the Attic with
> > "cvs add", but if someone removes it after you've modified it, you
> > might not know to do that. I bet there's a message when you update
> > ("...not safe to delete", or something to that effect), but you could
> > miss that.
> I don't recall any messages at all. Back in 2001, I created a test case,
> and it printed nothing. It was short enough that you wouldn't need to
> worry about lost messages. :-)

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
    # 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!
    # 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. ;-)