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-
