bug-cvs
[Top][All Lists]
Advanced

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

[bug #29058] checksum failure after patch -- user's changes lost


From: David Taylor
Subject: [bug #29058] checksum failure after patch -- user's changes lost
Date: Wed, 03 Mar 2010 20:38:12 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

URL:
  <http://savannah.nongnu.org/bugs/?29058>

                 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
                 Release: 
         Discussion Lock: Any
           Fixed Release: None
   Fixed Feature Release: None

    _______________________________________________________

Details:

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,
better:

(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:

  <http://savannah.nongnu.org/bugs/?29058>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

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