[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> I might be convinced about "P" status (although, personally, I like it),

Hmm, what would it take to convince you? :-)  My main arguments
  - 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> 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 
Jim> original file to .#whatever.

I strongly agree with Jim.  Some more thoughts on how it could be
  - 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

reply via email to

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