Reedick, Andrew wrote:
> As for the Webserver farm example, it's "bogus." Using timestamps to
> detect changed files isn't reliable (especially when you consider clock
> skew.) Checksums are a better idea. Use 'svn info' to get the md5 of
> the files that comprise the baseline. Compare the svn checksums against
> the production file checksums. Only deploy files with mismatched
> checksums. Problem solved without the use of unreliable timestamps or
> commit-times.
I don't get it... You want to check out another copy of content to add a
new server to a farm. How is this approach going to mesh with the
'get-if-newer' requests coming in browsers that have already cached a
copy from an existing server - or that will subsequently hit other
servers after loading this copy?
> In fact, you can fake out 'svn status' with timestamps. 'svn status'
> looks at the file timestamp (and maybe the size too) to determine if a
> file has been modified. So it's possible to modify a workspace file,
> use touch to restore the original timestamp, and svn will never
> notice...
Yes, there is a philosophical disconnect between svn itself depending on
timestamps internally and refusing to preserve them for other tools.
> Personally, the only use I have for preserving original timestamps is
> because it looks pretty.
Do you ever use a browser? A proxy cache? A web server that recompiles
and internally caches pages when they are modified?
> IMO, timestamps are a catch-22. They're either useful in very
> unimportant situations, in which case no one really cares if they're not
> preserved, or they're super-important, in which case you're admitting
> that you're relying on a very unreliable piece of information for
> critical processes instead of taking the time to implement something
> more robust and accurate, such as checksums.
Just about everything that has any concept of caching will use
timestamps as the only reasonably quick method to determine the need to
get a fresh copy. In many cases using commit time would be suitable to
maintain a consistent view, though - or having only one master checkout
with rsync or some other transport for the other instances.
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-12 03:23:49 CEST