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.
Dear Bo, Sorry I responded directly - here the message is once again - I got nor respond from you. Neither #1 nor #2 happens on my machine. I am the only developer working on this project (BV) and the repositoty is on the same machine (PC, Windows XP, SP2) on a second harddisk. Please have a look at the directory listings below. The first is BVX, which is not in CVSNT. BVX is the directory from which the project is copied to installation/setup directorie where it is packed and shipped. Most of the programming for Corrective Services is done here, and the updated source code is then replaced (with an /update_only flag) in a second directory: BV, which is in CVSNT. Both directories are mirrored - again with an /update_only flag - to another drive and to CD. CD mirroring sets back the archive bit of the files that are copied. 1. BVX (as it should be) after work was done: ... 19.01.05 19:04 64.541 _____ BVANZ.CBL 20.01.05 20:34 118.902 _____ BV1.CBL 20.01.05 20:34 235.251 _____ BVINFO.CBL 2.02.05 4:49 276.859 _____ BVLOE.CBL 2.02.05 21:39 322.142 _____ BVNR.CBL 2.02.05 22:26 163.900 _____ BVDSP.CBL 4.02.05 2:03 295.131 _____ BVEXIMP.CBL 4.02.05 3:38 108.984 _____ BVEXPLVZ.CBL 27.02.05 5:15 15.836 _____ BVREFTX.CBL 11.03.05 4:54 400.168 _____ BVINI.CBL 11.03.05 5:59 400.077 _____ BVDRUCK.CBL 11.03.05 6:00 755.647 _____ BVZUG2.CBL 11.03.05 20:37 203.499 _____ BVA14.CBL 11.03.05 20:37 297.046 _____ BVRWINI.CBL 13.03.05 21:38 304.976 _____ BVINSP.CBL -------------------------------------------------------- 21.03.05 15:23 239.523 ___A_ BVREORG1.CBL 24.03.05 13:50 277.183 _____ BVRW.CBL 31.03.05 18:03 76.895 ___A_ BVTPR.CBL 13.04.05 3:29 134.823 ___A_ BVRVVW.CBL 24.04.05 13:55 360.386 ___A_ BVRVZL.CBL 24.04.05 14:33 62.688 ___A_ BVSTAMM.CBL 24.04.05 14:33 4.816 ___A_ BVVRNO.CBL 2. BV: as it is now, after mirroring and commit to CVSNT, at 22:24, 24-04-2005 (the directory listing sorted by date/time): ... 19.01.05 19:04 64.541 _____ BVANZ.CBL 19.01.05 19:06 118.902 _____ BV1.CBL 2.02.05 4:49 276.859 _____ BVLOE.CBL 2.02.05 21:39 322.142 _____ BVNR.CBL 2.02.05 22:26 163.900 _____ BVDSP.CBL 4.02.05 2:03 295.131 _____ BVEXIMP.CBL 4.02.05 3:38 108.984 _____ BVEXPLVZ.CBL 27.02.05 5:15 400.077 _____ BVDRUCK.CBL 27.02.05 5:15 15.836 _____ BVREFTX.CBL 27.02.05 5:15 755.647 _____ BVZUG2.CBL 11.03.05 4:54 400.168 _____ BVINI.CBL 11.03.05 20:37 203.499 _____ BVA14.CBL 11.03.05 20:37 277.183 _____ BVRW.CBL 11.03.05 20:37 297.046 _____ BVRWINI.CBL 13.03.05 21:38 304.976 _____ BVINSP.CBL -------------------------------------------------------- 25.03.05 14:23 239.523 _____ BVREORG1.CBL 8.04.05 4:43 76.895 _____ BVTPR.CBL 15.04.05 2:53 134.823 _____ BVRVVW.CBL 24.04.05 22:24 360.386 _____ BVRVZL.CBL 24.04.05 22:24 62.688 _____ BVSTAMM.CBL 24.04.05 22:24 4.816 _____ BVVRNO.CBL The files to be updated/commited since the last commit are the ones below the dashes. I don't know how BVRW.CBL was treated, but fortunately, it's still the same. On the other six files, the timestamps are updated but not to the same time except for the last three. Strange behaviour. 3. BV: I did a similar thing with a text file: Before commit, after modification: 26.04.05 9:39 9.121 ___A_ Wasisneu.TXT After commit and edit (TortoiseCVS): 26.04.05 10:27 9.121 R__A_ Wasisneu.TXT The timestamp is updated, Wasisneu.TXT was changed besore, and the was no other updated Wasisneu.TXT in the repository. The read only bit set althoug TortoiseCVS edit command was done (with an unavoidable error message and abandonment of the operation) is another annoyance. I hope, we have a nearer view of the problem now. What about $0.02 ? Kind regards Thomas Bo Berglund wrote: > 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 >