[Top][All Lists]

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

Re: Checksum failure: serious problem or not?

From: Mark D. Baushke
Subject: Re: Checksum failure: serious problem or not?
Date: Mon, 22 Dec 2003 21:45:00 -0800

Hash: SHA1

Jim.Hyslop <address@hidden> writes:

> address@hidden [mailto:address@hidden wrote:
> [on eliminating 'P' status code]
> > Eric Siegerman writes:
> > > Hmm, what would it take to convince you? :-)
> > 
> > A whole bunch of people to agree (vociferously) with you.
> I hope there was a missing smiley, Larry. The problem is that most people
> who get confused by this issue probably don't subscribe to this list. Heck,
> most of them probably aren't even aware this list exists. So I don't think
> you'll hear all the grumbling and confusion that the two messages generate.
> For user interface issues like this, you need to stop thinking as a CVS
> developer, and put yourself in the mindset of the average CVS user. Sure, to
> you the distinction between 'P' and 'U' is important, and to me as a CVS
> administrator the distinction is of at least academic interest - but to most
> users, all that's important is the final result. As Eric has said, exactly
> *how* the file gets updated is an implementation detail. Most users do not
> need - or want - to know how it happens, they just want it to happen, and to
> know if there's a problem. I would submit that the majority of CVS users
> fall into this category - and they most likely will not be subscribed to
> this list, or to the bug-cvs list.

The distinction betwne U and P can be useful over a wan... there may be
other uses as well from an audit point of view as to how folks are
(ab)using their checked out trees. However, there is probably
insufficient distinction to make that very useful. 

> If someone were to submit a patch that substituted 'U' for 'P' unless a
> particular flag was set, would you at least consider committing that patch?


> [on checksum failure messages]
> > Feel free to submit patches.  The tricky part is that it's 
> > the *client*
> > that detects the problem.  The client doesn't have sufficient
> > information to do a merge (merges happen on the server), and 
> > there is no
> > client in local mode to do the detecting.
> Well, even in local mode the client must have some knowledge of how to do a
> merge, otherwise it could never merge a modified file.

In theory, the server had a copy of the client file to do the patch in
the first place and the client copy either became stale or was corrupted
while the server copy was being used to generate a patch.

> Could the following sequence work:
> - CVS renames the original file to a .# file name
> - CVS applies the patch to the original file
> - If the checksum on the file succeeds, delete the .# file
> - Otherwise, delete the patched file, rename the .# file back to its
> original name, somehow force the file's state to 'Modified' (brute force way
> would be to 'touch' the file) and restart the operation as a normal update
> on a modified file.

Hmmm... that will be very tricky...

> I haven't examined the code, so I don't know how easily that sequence would
> fit in with the existing code.

Look at the code. If you have a patch to suggest, it would be
interesting to see it.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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