Re: MTime resurrected

[Rick Yorgason]
> Wouldn't an acceptable default be to always update the local file
> time to the text-time, except when the local file time is newer?
> (i.e. Ensuring that the time never goes backward, even on a switch or
> revert.)
>
> That would never screw up a build system

Eh? It would screw up any build system based on the 'make' paradigm,
which is pretty common. It sounds like you may not understand quite
how 'make' works, so I'll explain:

With 'make', by default, you declare a dependency tree between source
files, intermediate build files, and final build targets. Then 'make'
uses timestamps to figure out what needs to be rebuilt and what is up
to date.

For example: say we declare foo.o to depend on foo.c and common.h.
(Why common.h? Because foo.c includes it. If you change common.h, you
are changing the meaning of foo.c.) The build rule to produce foo.o
will run if and only if one of the following is true:

- foo.o does not exist
- foo.o exists but is older than foo.c
- foo.o exists but is older than common.h
- Either foo.c or common.h needs to be rebuilt. (I.e., the algorithm
  is recursive.) This is more or less implied by the fact that if
  foo.c or common.h is rebuilt, it will then be newer than foo.o.

So, run 'make foo.o'. foo.o is built from foo.c and common.h and gets
a current timestamp.

Now do a 'svn update' or 'svn switch' which changes foo.c.

Current svn: foo.c mtime is set to the present time. It is now newer
than foo.o. [Of course you can set foo.o's mtime in the future, but
that's just breaking things _on purpose_.]

Your proposal: foo.c may or may not get a newer timestamp than it had.
If not, you lose. If so, this timestamp may or may not be more recent
than the last time you ran 'make foo.o'. If not, you lose.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/