|
From: | Derek R. Price |
Subject: | Re: How to tell CVS that it should use the proper date/time |
Date: | Thu, 08 Jul 2004 15:25:30 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 |
Jim.Hyslop wrote:
address@hidden wrote:The problem is that the CVS doesn't guarantee that the files are copied into the workspace in the same order in which they were checked in. SoI'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make?for derived files like y.tab.c and y.tab.h that might be checked in(these might be bad examples, but you know what I mean), unpleasant thingscan happen if their timestamps come out in the wrong order.I think I was unclear - I meant the timestamp that the file had before it was checked in, not the timestamp of the file when it was checked out. I *think* that's what the OP was looking for. In other words, if I last modified the file on June 30, and checked it in on July 1, currently when you check out the file, CVS will set its timestamp to the check-in time of July 1. If, instead, CVS set its time to the last modified time of June 30, how would that break make?
It wouldn't, but it could break the RCS archive file contract that says that internal commit timestamps will be increasing. This would in turn break operation of the -D arguments to various commands. It could also open up a minor security hole in that the server would now have to trust the client for timestamps.
It's possible that you could achieve the result you are describing by adding a newphrase to the RCS files so that timestamps and commit times were stored separately for each revision. I don't think you could cause any major havoc if those time stamps were then used instead of commit times to set timestamps just on checkout (not update).
Derek -- Get CVS support at <http://ximbiot.com>!
[Prev in Thread] | Current Thread | [Next in Thread] |