[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. 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. 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. I haven't examined the code, so I don't know how easily that sequence would fit in with the existing code. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (<http://www.leitch.com/>) Columnist, C/C++ Users Journal (<http://www.cuj.com/experts>) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
