The content of this page was written by Rick Yorgason: see <>.

Design: MTime Preservation

Nearly every modern operating system associates a "modified time" with each file on the system, updating it whenever the file is modified. This metadata can be very important, but Subversion currently offers no way to preserve it.

This design proposes adding a new 'svn:text-time' property to store the modified time of each file or directory in UTC time using the format 'YYYY-MM-DDTHH:MM:SS.UUUUUU'. The name of this property was chosen because it is already used in an identical manner by FSVS and svntar.



Modified time. In this specification, mtime will always refer to the modified time of a file as stored by the operating system. Under this specification, Subversion will sometimes alter the mtime to equal the value stored in svn:text-time.
System time. The current time according to the operating system at the time of the operation in question; aka now().
Commit time. The timestamp currently stored by Subversion indicating when the file or directory was committed.


A new client-side configuration option named 'mtime-usage' should be introduced to specify how Subversion treats a node's mtime during an update operation. It can be one of the following options:

mtime-usage obsoletes use-commit-times. If mtime-usage is unset and use-commit-times is true, the behaviour is identical to if mtime-usage was set to commit-time.


svn commit

svn update

(The following logic is applied after the file has been updated.)

svn checkout

svn merge

svn resolve

svn copy

svn rename

svn revert

Use cases

Control cases

These are cases that Subversion is currently used for, and are expected to continue to work identically.


The build system 'make' defines a specific set of output files for a specific set of input files. Whenever the output files are built, their mtime is set to stime. Whenever rebuilding, it checks to see if mtime of the the input files is newer than the mtime of the output files and rebuilds them if that's the case.


Log files

Log files are often opened and resaved, even when nothing is written to them. This is not expected to count as a modification.


Compiler-generated files

When building software, the compiler may be configured to output a compiler-generated file. These often get re-generated with identical output, only modifying the mtime. This is not expected to count as a modification.


Motivating use cases

These are some of the reasons that users require this feature.

Image compression

In this scenario, the user stores uncompressed images in one folder and then runs a script to compress the images and dump them in another folder. The compression tool can generate slightly different bitstreams on different computers. Both folders are required to be under version control, and should avoid recompressing images that have not changed.


Subversion as a backup tool

In this scenario, Subversion is primarily used to detect modified files and upload them to an off-site server; version control is only used in rare cases, such as a file being backup up after it was corrupted.


Finding documents by publication date

Some users maintain their mtime to refer to the publication date of a file. It should be possible to locate a document based on its mtime, even if that document was committed weeks after it was modified.


Web server

Web servers expose the mtime as the 'Last-Modified-Date' header in http requests, which is used in a variety of ways. Clients use it to determine whether or not the file needs to be re-cached, reducing bandwidth for the server. Search engines use it to determine if the page needs to be reindexed, or when the user requests to find a page matching a certain date range. Users use it when they need to determine if the information on a page is obsolete. Web servers also offer index pages, which show all the files in a directory and allow the user to sort by mtime.


Auto-props deficiencies

This proposal relies heavily on auto-props, and as a result, betrays some of the deficiencies extant in the auto-props system.

Most of the motivating use cases would benefit from having all users share the same auto-props. TortoiseSVN users can do this today using tsvn:autoprops, but there is no standard way to accomplish this. See Issue 1974: server-side config which 'broadcasts' to clients

Auto-props does not apply to directories. This means that directories cannot preserve mtimes without manually adding the svn:text-time property to all directories. See Issue 1989: make auto-props affect directories too

Auto-props only applies properties to newly imported/added files, so any existing files will have to have svn:text-time added manually when adopting the new feature. One solution would be to extend auto-props to allow the user to specify 'important' rules that should be applied on commit, rather than just on import/add. Another solution would be to add a command to svn that recursively applies the auto-props rules to a selected directory. I am not aware of any filed issues that request these features.


The content of this page was written by Rick Yorgason: see <>.

MtimePreservation (last edited 2013-12-16 11:21:42 by JulianFoad)