subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Yorgason <>
Subject Re: MTime resurrected
Date Fri, 17 Feb 2012 13:17:26 GMT
On 2012-02-17 6:41 AM, Fuhrmann Stefan (ETAS/ESA1) wrote:
> I'm not championing the mtime feature but if
> someone demonstrates a compelling use-case, it
> should neither be hard nor risky to implement it.
> -- Stefan^2.

There have been quite a lot of use cases presented over the years. A is 
mine; B and below are other use cases that I've summarized:


A) Texture Compression: Both compressed and uncompressed textures are 
stored in version control, with a script creating the compressed 
textures whenever the uncompressed texture is newer. Currently, updating 
assigns now() to both the compressed and uncompressed files, which often 
screws up the script. I'm also a programmer, so using use-commit-times 
system-wide is undesirable.

B) Vendor branch management. I've never done vendor branch management, 
so I'm not sure what this user meant, but maybe you can divine it from 
his post:

C) Including third-party DLLs in your build system. I presume this is 
similar to (A), although maybe there's some additional subtleties I'm 
not recognizing, because he says "you absolutely need to have the 
correct modification date or you can really screw up someones PC."

D) Using SVN as a backup tool. Restoring your backup would set all your 
mtimes to now(); I assume everybody can imagine how obtrusive it would 
be if all the dates on your computer got reset to now(). 
use-commit-times can be used as a partial solution, but the granularity 
would never be as good as you would like.

E) There were many references to "document focused" uses without many 
concrete use cases, but I can imagine a simple one: you check out a 
folder full of hundreds of documents, and want to find one that was 
published on March 3rd. If the file was committed in a timely manner, 
use-commit-times or svn log are possible, if cumbersome, solutions. If 
it wasn't committed in a timely manner, you're SOL.

F) Last-modified-date in web content. This one has a lot of 
repercussions, listed below. It's also worth noting that web content is 
usually intermixed with code, so using use-commit-times system-wide is 
undesirable. I saw a few references to this one, but the most notable is 
Robin Cover's epic memo:

F1) Web servers use the last modified date to inform browsers when they 
need to re-cache images and pages. At come point you have to do a fresh 
checkout, bumping the dates of every file, resulting in wasted 
bandwidth. Even using use-commit-times would bump the dates of any files 
that went live before they were committed.

F2) Search engines use the last modified date with the assumption that 
it represents the 'published' date. Users may also use it for the same 
reason. use-commit-times is a partial solution, but not granular enough.

F3) Most web servers offer some way to index files in a directory, 
showing you the last modified date, with some option to sort by date. 
use-commit-times is a partial solution, but not granular enough.


Before anybody calls me out on this, my suggested heuristic for setting 
the local timestamp is not intended to solve all of these problems. I'm 
advocating the design worked out by Edmund Wong and Philipp Marek:

The heuristic I'm suggesting is merely to simplify the user interface by 
ensuring that, by default, svn does the right thing as often as 
possible, while being no worse than the current system. It would also 
reduce the importance of some of the features presented in their design, 
since you could always get the right mtime by using the fresh checkout 


View raw message