Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
CVSNT 2.5.01 B1927 w/TortoiseCVS 1.8.13 updates timestamps of the files
committed so they loose their original timestamps.
I found something obout this problem in
http://sourceforge.net/tracker/?group_id=48103&atid=451972&func=detail&aid=1069471,
and the answer was: " This is a standard feature of CVS, and TortoiseCVS
cannot change this behaviour."
Maybe. But the CVSNT Manual ('cvsnt–Concurrent Versions System
2.5.01.1921' of March 29, 2005) does not explicitly mention that
timestamps of the original (updated or new) files committed to the
repository are updated to the time when the files are commited.
Instead, in 'A sample session', comments to $CVSEDITOR environment
variable I found:
"The next update will clue cvsnt in to the fact that the file is
unmodified, and it will reset its stored timestamp so that the file will
not show up in future editor sessions."
Later:
"... if the timestamp differs with the actual modification time of the
file ..." and so on, What's important is: there's an "actual modification
time of the file" and: "The timezone on the timestamp in CVS/Entries
(local or universal) should be the same as the operating system stores for
the timestamp of the file itself."
Later, the document says:
"For your protection, cvsnt will refuse to check in a file if a conflict
occurred and you have not resolved the conflict. Currently to resolve a
conflict, you must change the timestamp on the file."
I agree, of course. And I remember: I did not have this problem when I
used CVSNT 2.0.58d w/TortoiseCVS 1.4.5 - the timestamps remained the
same as they were when I finished work on them. Because I'm using a Make
utility and a mirror drive that is served using timestamps too, so it's
kind of important that the timestamps remain unchanged when having
committing to the CVSNT repository. With the new version, at least,
after having committed, I will 'Make' the whole thing again because the
Make utility detects the source code's changed timestamps comparing them
to the corresponding object code's timestamps, and it has has no clue of
an unchanged file contents. So it wants to do it again.
I'm not shure this is the duty of Concurrent Versions System or any
version control system.
Kind regards
Thomas