> -----Original Message-----
> From: Robin Cover [mailto:robincover_at_gmail.com]
> Sent: Thursday, March 13, 2008 3:53 AM
> To: Subversion Users List
> Subject: Once more: Subversion and file modification time (mtime)
>
> [1] Introduction
>
> This communication raises once again the question of Subversion
> (not) storing/recording file mtime values in an SVN repository,
> and (thus not) making last-modified date/time values available
> to other SVN operations, as required by predictable classes
> of end users and their documented use cases.
>
> The goal here is to provide yet one more use case, and to seek
> input from the core Subversion developer team [1n] about
> realistic prospects for fixing this problem -- now documented
> in several hundreds of user email messages since 2002. No
> FAQ or wishful thinking is going to make this problem disappear,
> as far as I can see.
You might get more traction if you can propose a solution or
compromise that works for both sides. For example, since timestamps and
versioning can really confuse make[1], ClearCase comes with a special
version of make (called omake) that checks if the version changed
instead of relying solely on timestamps. Version control systems are
code-centric which implies build-centric so breaking make seems to trump
unbreaking other use cases.
Maybe 'svn co' would preserve the timestamp, but update and
revert (or any command that modifies an existing workspace) would use
current time? Update and revert would have a switch to allow for
preserving the original timestamp.
[1] Example:
Foo.c r99 has a timestamp of Monday
Foo.c r100 has a timestamp of Tuesday
Build r100 on Wednesday,
so foo.o has a timestamp of Wednesday.
Roll Foo.c back to r99 (timestamp of Monday)
Rebuild. Make does nothing since:
Foo.c - timestamp of Monday
Foo.o - timestamp of Wednesday
Which leaves you with a Foo.o that was built with r100 instead
of r99
ClearCase's omake would see that Foo.o was built with r100 and then
rebuild it using r99.
*****
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. GA623
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-13 15:49:09 CET