[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: erroneous cvs checksum failures?

From: Mark D. Baushke
Subject: Re: erroneous cvs checksum failures?
Date: Wed, 24 Nov 2004 09:31:43 -0800

Hash: SHA1

Stephen Degler <address@hidden> writes:

> I see the following problem, I'm not sure what to do (if anything) about
> it.  If there is a new revision of foo.c created with no diffs from the
> previous version, cvs update reports "checksum failure after patch to
> foo.c, will refetch" on a subsequent cvs update to a tree where foo.c is
> at the lower revision.  It also gives "cvs update: warning: `foo.c' was
> lost.", which is a disturbing message to see even if the results are
> innocuous.

Your description would seem to indicate that someone is playing with
adding and deleting revisions of the file using 'cvs admin' or via
wholesale replacement of the ,v file in the repository. I would not
expect that kind of behavior without other interventions...

> The server is indicating 0 length patch and the client's checksum
> differs due to keyword expansion.  I believe that the repository was put
> in this state from a developer manually copying a version from a branch
> and commtting it to the head.  The keywords stored in the text of the
> revision in the repository do not match either the current revision or
> the previous one (they reflect the revision of the branch).

Keyword expansion could indeed mean that a simple 'Patch' operation
would fail and subsequently require cvs to send the entire updated file
over the protocol. It should be able to do this without any problems to
worry you.

> On the client side of things, I see the message at line 1621 of client.c
> with version 1.12.9.
> Is there a bug in the server or client handling of this case?

I don't think so.

> And is it the problem the handling of the commit or the subsequent
> update?

I am not sure what you are asking. cvs tries to send as little across
the client/server protocol as possible. It does the merge on the server
and then tries to determine the delta that should be sent back to the
client. If the delta it sends back does not result in the reassembly of
the file as expected and calculated via checksum, it falls back to
sending the entire file over the link.

If you are seeing this behavior for ALL updates, then you may have
problems. If it is just for the one file, then I would not worry about
it too much.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]