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:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256#desc8
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."
http://subversion.tigris.org/issues/show_bug.cgi?id=1256#desc22
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.
http://subversion.tigris.org/issues/show_bug.cgi?id=1256#desc23
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:
http://svn.haxx.se/users/archive-2008-03/0462.shtml
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:
http://svn.haxx.se/dev/archive-2010-02/0127.shtml
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
workaround.
-Rick-
Received on 2012-02-17 14:18:22 CET