> -----Original Message-----
> From: Mike Brenner [mailto:mikeb@mitre.org]
> Sent: Tuesday, August 29, 2006 9:54 AM
> To: users@subversion.tigris.org
> Subject: Re: Keeping last-modified dates
>
>
>
> I disagree that modification dates "are fairly
> useless". I often use modification data as
> an quick method of guessing the contents of files.
>
> In many configuration management systems
> the modification date serves as important
> metadata.
Yes, but to support make. Many CM systems use the checkin date
by default, and will touch a file on checkout. Many CM systems were
written to support code which needs to be built, which means always
touching the timestamp so that make will pickup the new file version.
Personally, I don't trust timestamps or 'ant/make clean' and
will create a fresh working copy from scratch in order to ensure a clean
(CM) build.
>
> Changing the data on a file strongly
> implies that the content has changed.
> When software gets more complex, we
> need to know whether we have the original
> version of a file or the changed version.
Then you need to do real audits against clearly established
baselines. You could memorize the timestamps for every file for every
release but you still can't be 100% sure that the file contents are
correct. Plus a timestamp won't tell you if you're missing files or
have extra files...
>
> Stability and debugging often depend on
> having an original, unmodified file
> for everything except the unit under test.
Actually, you need to know that you're testing against the
correct code baseline. Timestamps won't tell you that with 100%
certainty. It also means that you need a rock solid build and
deployment process.
>
> We should evolve subversion towards
> keeping the modified date.
You need to evolve your CM practices and develop dependable
build, deployment and audit processes. Timestamps are a lazy,
incomplete crutch that is guaranteed not to guarantee anything.
(All IMHO based on experience based on much pain and suffering
in the past.)
*****
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. GA624
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 17:20:07 2006