Subject: Re: cvs 1.11.10 will be imported
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Frederick Bruckman <email@example.com>
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
# 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