RE: timestamp preservation design (issue 1256)

> From: Jack Repenning
>
> On the other hand, clock skew is *not* a problem for either approach,
> because anyone asking for timestamp preservation already understands
> this, and has heard of NTP.

I don't know for sure (I don't even know where to find this out), but what time zone does the FS keep the timestamp in? If it keeps the timestamp in UTC, then there is no problem (or at least not as big a problem). On the other hand, if the FS maintains the timestamp based on local time, then there is a problem when developers are working in different time zones.

> if you version output files, they can look
> like they need to be rebuilt when this is not so. You will say to me
> "don't do that," but you have perhaps never worked in a system that
> took hours to generate certain output files, and days to build the
> entire system; it changes your perspective on these things a mite.)

Instead of storing the timestamp, why not store an offset: The youngest file in the WC gets an offset of 0. Each file then gets a time offset that represents the time difference between the youngest file. This offset is what then gets stored.

When it someone does a checkout, the local current time is chosen and all files get the timestamp "currentTime - offset". This would resolve the generate issue.

Since I don't know much about timestamps, I did a quick google search. This is a link to a little utility that addresses the problem (with a brief description of the problem):

http://www.codeproject.com/file/TimeStamp.asp

This is a windows utility. Don't know anything about other FS's.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 19 18:49:16 2003