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.
The following cases for timestamp modification is what I have observed:
1. Local file is unmodified, but a new revision exists in the repository
When you do a cvs update to retrieve the changes in this file then the
local file will be automatically modified because of the merging and the
timestamp changes just like it would if the normal editor is used.
The CVS metadata is changed to reflect this timestamp change too so
the file remains in its unmodified state.
2. Local file is modified and there is also a repository modification
This is pretty much the same as above, the merge takes place and the file
is now saved with a new contenst and timestamped as "now".
In this case the CVS metadata keeps track of the fact that the file is
changed locally too.
So in both cases the file timestamp changes to "now" and this is very
important because otherwise any normal make tool would not understand
that it needs to recompile the files the next time.
Consider case #1 above.
If your nonmodified file would be updated and the timestamp set to the
repository commit time, then this could well be several days or even
weeks back in time. If you had built your project say two hours before
the cvs update then the object files would be more recent than the source
file and the next make would not compile in the changes you updated from
CVS. Not good....
Same is true for case #2 also, you could for example have edited your file
yesterday and built your project two hours ago. If the timestamp remained
as the latest of your edit time or the CVS commit time it would still be
earlier than your last build and the new contenst would not be included
into your next build. Not good too...
So I think that the way CVS operates is the best way:
- New checkouts get timestamps equal to the repository commit time.
- Updates in the current sandbox set the timestamps to "now" thus
forcing a compileation on the next build. Note that this happens
only if your unchanged local file receives new data on update.
Files that have not cahned anyware retain their timestamps.
I think that you should not worry about timestamps, let make figure
it out instead.
My $0.02
/Bo
-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf
Of Thomas Brackel
Sent: den 26 april 2005 05:54
To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
Subject: [cvsnt] CVSNT 2.5.01 B1927 updates timestamps
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
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs