MTime resurrected

[Rick Yorgason <ri...@longbowgames.com>]

So, I've found myself needing the MTime extension that's been under 
discussion since 2003 (Issue #1256) and just spent some time reading the 
various posts associated with it.

In 2010 Edmund Wong wrote a nearly complete spec for mtime preservation, 
after which some discussion narrowed it down, but it seemed to have been 
forgotten again.  For reference, the thread starts here:

http://svn.haxx.se/dev/archive-2010-02/0127.shtml

While reading through the posts, I wanted to reply to something. I 
normally wouldn't have resurrected a two year old post, but given that 
we're close to being able to measure this bug on a decade scale, I 
figure two years isn't all that long. The message I'm responding to is here:

http://svn.haxx.se/dev/archive-2010-02/0131.shtml

Where Philipp Marek wrote:
>> >> + ... This functional specification takes
>> >> + the tact of setting the 'svn:mtime' property to the current
>> >> + mtime as it will give the user at least a starting point
>> >> + to which to make their statistical/informational mtime references.
>> >
>> > So there's no way to have some part of the WC with mtime-storage, and
>> > another without? I'm thinking about generated binaries that you want to
>> > keep.
>>
>> Pardon me for being a bit dense. Do you mean that generated binaries
>> (or binaries in general?) should not have the 'mtime' stored?
> No ...
> If you've got some source files, you *don't* want mtime stored for them, so
> that "make" knows what to re-compile.
> But if you want to keep the generated binaries (and especially if there's some
> 3rd party dependence, eg. on some DLLs), you *want* the mtime - because that's
> the easiest thing to compare over a phone line.
>
> So it's entirely possible that some files shall have the mtime stored, while
> others shouldn't.

(Reminder: Philipp used the term 'text-time' to refer to the mtime as 
recorded by svn.)

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, and would usually give the 
text-time to people wanting it. For people who absolutely need one 
behavior or the other in every edge case, there's always configuration 
options.

I think the only options you would need are use-commit-time (which you 
already have) and use-text-time. I don't think you would need an option 
to use the current behaviour; the only use case anybody has brought up 
for the current behaviour is build systems, but in that case you don't 
care how fragile the file time is, as long as it always goes forward, 
and the solution I'm proposing is already less fragile than what we 
currently have.

(Actually, it's not easy to think of a good use case for use-commit-time 
either, but I suspect this proposal is going to be controversial enough 
as it is without suggesting that use-commit-time meet the chopping block 
too.)

-Rick-

Re: MTime resurrected

[Peter Samuelson <pe...@p12n.org>]

[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/