[tex-live] svn timestamps too new

[Karl Berry]

Next svn question: turns out that svn does not store mtimes.  It stores
commit times, on a per-revision basis.  What this means is that all the
files in the tree have a timestamp of late December/early January
instead of their "real" modification time (years old, in many cases).

The "per-revision basis" means that, in practice, it's not possible to
fix the mtimes with the current tree.  In most cases I checked in
hundreds or thousands of files at a time, so I see little point in
"choosing" an mtime for all files in each set of committed files.

So, to fix this, I'd have to start over with a new tree, and commit the
files essentially one at a time, changing the mtimes afterwards.

My question is, is it worth it?  I'm inclined to say no, that we can
live with the checkin time as the "starting" mtime.  But I wanted to
mention it, so you-all weren't surprised when you saw the files were all
"new".

There will be some agony with the Makefiles, I'm sure, but I think that
can be dealt with.  (My next step is try a test build, anyway, so I'll
see how bad it is.)

Below is the mail from an svn person on which I'm basing this.

Thanks,
Karl


Date: Mon, 23 Jan 2006 12:01:01 +0100
From: Ryan Schmidt <subversion-2006Q1 at ryandesign.com>
To: Karl Berry <karl at freefriends.org>
Cc: users at subversion.tigris.org
Subject: Re: mtime fixup

[...]

The repository does not store mtimes at all. It only stores the  
commit time.


You can change the commit time after the fact, if you install a pre- 
revprop-change hook allowing such changes. Simply set the svn:date  
property of the revision. Note that the date applies to the entire  
revision, not to individual files. If you want to be able to set the  
date of individual files, you must commit them in individual revisions.


Another option: There is the unofficial meta-data-versioning branch  
of Subversion which tracks file mtimes among other things, if you're  
interested in putting that together and building it.

[I certainly don't want to depend on an "unofficial" branch. --karl]