[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