[Top][All Lists]

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


From: outre99
Subject: unsubscribe
Date: Fri, 05 Mar 2010 08:01:50 +0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100216 Thunderbird/3.0.2

On 3/5/2010 12:01 AM, bug-cvs-request@nongnu.org wrote:
Send Bug-cvs mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bug-cvs digest..."

Today's Topics:

    1. [bug #29058] checksum failure after patch -- user's changes
       lost (David Taylor)


Message: 1
Date: Wed, 03 Mar 2010 20:38:12 +0000
From: David Taylor<INVALID.NOREPLY@gnu.org>
Subject: [bug #29058] checksum failure after patch -- user's changes
To: David Taylor<taylor+gnu@candd.org>, dtaylor@emc.com,
Content-Type: text/plain;charset=UTF-8


                  Summary: checksum failure after patch -- user's changes lost
                  Project: Concurrent Versions System
             Submitted by: taylor
             Submitted on: Wed 03 Mar 2010 03:38:11 PM EST
                 Category: Bug Report
                 Severity: 3 - Normal
               Item Group: None
                   Status: None
                  Privacy: Public
              Assigned to: None
              Open/Closed: Open
          Discussion Lock: Any
            Fixed Release: None
    Fixed Feature Release: None



Sometimes when doing a ``cvs update'' a user's local changes
to a file will be lost by cvs.  You see output like:

cvs update Makefile
P Makefile
cvs update: checksum failure after patch to ./Makefile; will refetch
cvs client: refetching unpatchable files
cvs update: warning: `Makefile' was lost
U Makefile

What has happened is that CVS client *thought* that the file was
unmodified, so it told the server that it was unmodified.  The
server noticed that the file was modified in the repository,
created a patch, and sent it and a checksum.  The client applied
the patch and checked the checksum -- which didn't match because
the file *IS* locally modified.  So, it threw away the file and
got an unmodified version from the server.

One way that this can happen is if the user saves the file on
one system and then before the NFS information gets flushed
to disk, issues the cvs update command on a different system.

The client looks, sees old timestamp information that matches
the timestamp in the CVS/Entries file, thinks the file is
unmodified and tells that to the server.  When it gets the
patch back from the server, the write that was issued earlier
is now visible on the machine where the commit is occurring
(the file attributes were refreshed by nfs).

What I think that cvs should do is to backup the file before
applying the patch.  Then if the checksum fails, the user's
changes aren't lost.

It could then do one of two things:

(1) restore file file from the backup and issue an error
message.  The changes aren't lost and a reissued cvs update
will see the new contents and ``do the right thing''.  Or,

(2) tell the server that the file *IS* modified, send the
file contents the way it normally does for modified files,
and proceed accordingly.  Only fail if the latter fails.


Reply to this item at:


   Message sent via/by Savannah


Bug-cvs mailing list

End of Bug-cvs Digest, Vol 74, Issue 1

reply via email to

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