[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Checksum failure: serious problem or not?
From: |
Eric Siegerman |
Subject: |
Re: Checksum failure: serious problem or not? |
Date: |
Fri, 19 Dec 2003 17:51:23 -0500 |
User-agent: |
Mutt/1.2.5i |
On Fri, Dec 19, 2003 at 03:22:31PM -0500, Larry Jones wrote:
Larry> Eric Siegerman writes:
Larry> >
Larry> > The "P" status and the "checksum failure" message should both go
Larry> > away. (Patched and fully-refetched files should all be labelled
Larry> > "U".)
Larry>
Larry> I might be convinced about "P" status (although, personally, I like it),
Hmm, what would it take to convince you? :-) My main arguments
are:
- User confusion; it's a fairly FAQ, and a needless one
- The fact that CVS distinguishes "P" from "U" implies
(wrongly) that they're different in some important
source-controlish way -- commensurate with, say, the
distinction between "U" and "M", or between "M" and "C", or
between "A" and "?". In fact, as far as source control is
concerned, "P" and "U" are identical. In other words,
there's a layer mismatch. The other codes all reflect
differences at the "source-control layer" (to rather stretch
the OSI model) but "P" is different from "U" only at a lower
layer. I believe it's this mismatch that's the cause of all
that user confusion.
Larry> but I strongly disagree about the checksum failure message. It
Larry> indicates a serious confusion about the state of the working file that
Larry> the user *must* investigate. It indicates that there were local changes
Larry> to the file that CVS doesn't know about and is in the process of
Larry> discarding. Unless you like losing changes, you must figure out what
Larry> happened to get you into that state and ensure that it doesn't happen
Larry> again in the future.
On Fri, Dec 19, 2003 at 04:45:54PM -0500, Jim.Hyslop wrote:
Jim> Well, there's a couple of problems with that. First of all, the error
Jim> message does not say anything like that - the message is quite terse and
Jim> most users wouldn't know to check their files. Second, by the time the
Jim> operation completes, any trace of the original file is gone, so it's almost
Jim> impossible to investigate exactly what changed - or what CVS _thought_ had
Jim> changed. The original file is not backed up.
Jim>
Jim> So, I think CVS should be modified either to:
Jim> 1) eliminate the "checksum failure" message, or
Jim> 2) modify the error message to make it clearer what happened, and rename
the
Jim> original file to .#whatever.
I strongly agree with Jim. Some more thoughts on how it could be
improved:
- Saving the user's file as .# backup is the least it should
do. Better would be to abort the update, leaving the user's
file unchanged.
- Best of all would be to fall back to a merge instead of to
the current overwrite. This wins because it reduces the case
to one the user is already familiar with -- saving the .#
file falls out transparently (from the user's point of view;
I don't know about the code's), and the error message can
probably be eliminated after all.
- Local mode should offer the same level of protection as does
client/server. (Even though the proximate reason that the
error is detected in client/server (failed patch attempt)
doesn't apply to local mode, the underlying error condition
is just as severe, and just as worthy of action by either the
user or by CVS.)
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau
RE: Checksum failure: serious problem or not?, Jim.Hyslop, 2003/12/19
RE: Checksum failure: serious problem or not?, Jim.Hyslop, 2003/12/19
RE: Checksum failure: serious problem or not?, Jim.Hyslop, 2003/12/22
Re: Checksum failure: serious problem or not?, Larry Jones, 2003/12/23