Re: Incorrect, repeatable, unremovable "in the way" errors

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi John,

>    Please click here for 4,210 complaints and reports
>related to this problem dating back to 1999.
>
>http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=%22move+away%22+CVS+update&btnG=Google+Search

Yes, way too many odd things happen when the CVS/Entries file is
corrupted by such things as the server running out of diskspace or
memory or a user untarring a copy of a new release on top of a cvs
checked out tree and doing an update and getting lots of those kind of
problems for files that were new to the system.

>>    But the problem is induced by an incorrect timestamp on
>>a commit from one client, and affects other clients via the
>>server.  It's apparently possible to check in with a timestamp
>>in the future from the server's perspective, which causes
>>problems.  A clock inconsistency check on commit would prevent
>>this problem.

Are you trying to point us at examples of clock inconsistency that arise
- From someone moving a tarball of a checked out tree into a different
timezone? Or, possibly someone mucking about with the time on their
local machine between one cvs update and the next one?

Or, are you trying to report something else?

I had the impression from your message that you had an explicit set of
circumstances that would reproduce the problem. If so, please inform us.

I do not know of a way to checkin a commit with a timestamp in the future
(from the server's perspective) that does not involve the 'cvs import -d'
command. If you know of a way, tell us.

        -- Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/2upc3x41pRYZE/gRApUPAKDYRqc4x01ewungm1Y+ciEZjSF6rwCcDidJ
kKJwEQ7m16Cw+2peGwKf3x8=
=M65W
-----END PGP SIGNATURE-----