On 8/29/2006 12:18 PM, Steve Fairhead wrote:
> Greg Thomas said:
>
>>>
> On Tue, 29 Aug 2006 14:36:24 +0100, "Andrew Webb"
> <andrew.microi@gmail.com> wrote:
>
>>As Steve Fairhead says in a recent, related thread: "one could argue
>>just as hard for timestamps to be preserved *because* of makefiles".
>
> You could try, but I don't think you would be very successful. If you
> preserve modification times, you fall in to the following trap:
>
> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
> 2-Aug: Bob modifies, commits foo.c
> 3-Aug: Alice does a make. foo.c is compiled,
> creating foo.o timestamped 3-aug.
> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
> Alice does a make. foo.c is not compiled, despite being
> changed since the last compilation, as foo.c is timestamped
> 2-Aug (when Bob made the change), which is before foo.o was
> created (3-Aug).
> <<
>
> This is fairly bogus. So Alice has edited a file, thrown it away, and
> reverted to an earlier version. With or without a VCS, this is (as I said
> earlier in another post) the sort of situation that breaks makefiles anyway.
> I'd do a make clean.
Alice never edited the file. She just checked it out, and used svn to
update it a few days later. svn moved the date forward from the
previous modification date in the repos (1-Aug) to the new modification
date in the repos (2-Aug). Unfortunately, the build system won't notice
that change, because it's only comparing to the date on foo.o (3-Aug).
I imagine even worse examples could be constructed if you allow Alice
and Bob to have inconsistent clocks.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 19:55:52 2006