[cvsnt] Re: Tortoise error or CVSNT error?
Thomas Brackel
tbrackel at gmx.de
Wed Apr 27 17:33:47 BST 2005
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
>
More information about the cvsnt
mailing list