Re: timestamp preservation design (issue 1256)

At 5:38 PM +0200 6/20/03, Olaf Hering wrote:
> > For example, if you backdate a working copy via 'svn up', a .c file
>> will have an older timestamp than it's .o, even though the .o *needs*
>> to be rebuilt. But 'make' won't do it. So how does the simple
>> behavior help build systems at all?
>
>up should touch the file with the current time, co and export should
>preserve the commit time. That is what cvs does, at least.

I think Olaf has finally enabled me to understand why CVS does it
this way. It's an optimization thing:
* checkout provides commit timestamps (the vintage of the file
itself), because that's sometimes useful, and it's reasonably
build-safe (you're starting from a blank slate).
* update, on the other hand, provides as-loaded timestamps, in order
to ensure builds do the right thing. This sacrifices the "file
vintage" information to the higher good of correct builds.

Put another way: if you want vintages, use checkout. You're probably
doing something like backup or export/import or audit or something
else administrative, not developing, anyway. If you want to develop,
then you desperately want your builds to do the right thing, and you
can afford to sacrifice the "vintage" semantic to get that.

I'm not sure I *like* this: seems too complicated, obscure, and
undocumented (/me checks his cedarqvist just to be sure--yeah, no
reference to that here!). But at least, now I *understand* it.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94015
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org