> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Friday, July 11, 2008 12:11 PM
> To: Mark Phippard
> Cc: Ben Collins-Sussman; Karl Fogel; users_at_subversion.tigris.org; Ryan
> Schmidt; ??; Norbert Unterberg
> Subject: Re: Subversion Problem - How to save file modify time?
>
>
> Did those systems do anything sensible when then committing system
> clocks were in the wrong century or if files were dated in the future?
> One advantage of using commit times is that they can be forced to be
> consistent.
>
<tongue_in_cheek>
Anyone who uses Subversion in spite of Subversion's less than
bulletproof merging and merge tracking, won't be too concerned about
bogus timestamps.
</tongue_in_cheek>
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.
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...
Personally, the only use I have for preserving original timestamps is
because it looks pretty. It could also be useful for vendor code or
external code. There's no guarantee that the vendor/external code was
versioned properly or distributed using good configuration management
practices, so a timestamp could become a crucial piece of research
information. But then you can always check-in a snapshot of 'ls -al'.
But that's clumsy and relies on a manual process to preserve
pre-versioned meta-data. Meh.
Another potential use for timestamps is to preserve order. A series of
images might only make sense when viewed in time order. Of course this
assumes you didn't add a sequence number to the filename for some
reason. And since timestamps aren't written in stone, it's not a
reliable method.
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.
A possible alternative would be for the OS to maintain a standard
checksum. Instead of comparing the OS timestamp to the SVN timestamp,
you would be comparing the OS checksum to the SVN checksum.
> > My problem with this
> > has always been the design. I do not think you can do this feature
> > properly on top of Subversion's repository today.
>
> > Using a versioned property sucks. That means you have to carry
> around
> > the property information in the working copy and every commit in
> > theory needs to update it. This fouls log and diff etc..
>
> It would be nice to have the value stored whether you use it or not,
> though, with tools to view it and restore it even if you don't restore
> by default.
Maybe a hidden property? Generally speaking, file timestamps are only
useful outside of Subversion. Diff and log shouldn't care, whereas ls
would want to display timestamps.
> Or worse, if you accidentally do something that touches the timestamps
> on your working directory (perhaps copying to a new location) and
> commit, should that be a new revision for every file?
Make it an optional argument or setting. IIRC, in ClearCase you could
force a check-in of an unchanged file. There was also the "-ptime"
option on check-in which would allow you to preserve the file's actual
timestamp, instead of defaulting to the commit time. Whereas on the
checkout, "-ptime" would restore the file with the saved timestamp
instead of current time.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
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-11 23:36:29 CEST