Jim.Hyslop wrote:
[EMAIL PROTECTED] wrote:
I'm not sure I follow this. How would using the timestamp of the fileThe problem is that the CVS doesn't guarantee that the files are copied
instead of the time of checkin break make?
into the workspace in the same order in which they were checked in. So
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 things
can 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>!
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
