Timestamp handling in checkout vs update
Harper, Don
I have observed and read in the archives that cvs sets file timestamps to
the commit times when doing a checkout operation but sets them to the
current time when doing an update. What is the rationale for this? It
seems
to me that operations such as 'update -C' should set the timestamp back to
the commit time just like checkout.
Any information would be greatly appreciated.
Don Harper
Donald Sharp
>
> I have observed and read in the archives that cvs sets file timestamps to
> the commit times when doing a checkout operation but sets them to the
> current time when doing an update. What is the rationale for this?
Suppose file foo.c. Which creates foo.o. and ultimately foo
Suppose the date is today.
foo.c version 1.2 date stamp in repository is 12/1/01
foo.c version 1.1 date stamp in repository is 1/1/01
While your local copy version 1.1 date stamp is from 12/15/01.
You have compiled foo.o and foo. With time stamps on 12/16/01.
Now suppose you update foo.c to version 1.2.
Under your proposal the timestamp would be set back to 12/1/01
for foo.c Thus making make systems think the foo.o and foo files
do not need recompilation.
Under the current mechanism. foo.c gets todays date time stamp 1/7/02.
The make system sees that foo.c is newer than foo.o and foo. Thus
a rebuild is needed.
donald
> It seems
> to me that operations such as 'update -C' should set the timestamp back to
> the commit time just like checkout.
>
> Any information would be greatly appreciated.
>
> Don Harper
>
>
>
>
>
> _______________________________________________
> Info-cvs mailing list
> Info...@gnu.org
> http://mail.gnu.org/mailman/listinfo/info-cvs
Mike Castle
> seems
> to me that operations such as 'update -C' should set the timestamp back to
> the commit time just like checkout.
Consider make.
You modify the local file, make. You now have at least an object file, if
not an entire executable built with that modified file.
You do up -C.
Now, if it resets the date back to the original date, a subsequent make is
going to see that the source file is older than the object file, and is not
going to rebuild the system.
Not a good scenario.
Better to have up (-C or no) use the current time so that make will do a
rebuild.
mrc
--
Mike Castle dal...@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
Eric Siegerman
> the commit times when doing a checkout operation but sets them to the
> current time when doing an update. What is the rationale for this?
The update behaviour is so that a subsequent "make" will notice
that the file has changed, and rebuild anything that depends on
it. One wants this even if it was a "cvs update -C". Sometimes
CVS's behaviour can be a pain -- but doing "cvs update; make" and
having the newly-fetched changes NOT included in the build can be
more of one!
The checkout behaviour is because partial makes aren't (presumably)
an issue on an initial checkout, and so it's (presumably) safe to
set the files' timestamps to something more useful to humans.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. er...@telepres.com
| | /
One ring to rule the mall.
- Movie review headline, eye Magazine