Re: erroneous cvs checksum failures?

[Mark D. Baushke]

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

Stephen Degler <Stephen.Degler@twosigma.com> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBpMV/3x41pRYZE/gRAjDyAJ0XDRcwsCeZCJKfkQUmV1uNRwsXmACfbXzt
mVZ85tR33xZ+M5nVInzRIog=
=EDu8
-----END PGP SIGNATURE-----