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/
_______________________________________________
Bug-cvs mailing list
Bug-cvs@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-cvs
