Thanks for your reply, Ryan. I just ran some new tests: when I check out a new working copy (just a small subdirectory of the repo in this case), I get the right timestamps. And, when I delete a file in that newly-checked-out directory and do an svn update, I also get the right timestamp.
However, the behavior is different in the original directory tree that I imported. That is, deleting a file and updating gives the updated file the (wrong) timestamp of the HEAD revision. Perhaps I should just check out a new working copy. Still, I'm perplexed. On 1/25/2012 3:30 PM, Ryan Schmidt wrote: > On Jan 25, 2012, at 14:07, Alexander Shenkin wrote: > >> What I *thought* this was supposed to accomplish was that, if you were >> to checkout a new working version of the repository (and if you had >> TortoiseSVN "set file dates to the 'last commit time'", or perhaps ran >> svn checkout -r COMMITTED), your files would have their original >> last-modified dates (aka timestamps, aka mtimes). However, when I >> delete a file and do an svn update, the replaced file has the timestamp >> of the HEAD revision in the repository. That is, the most recent file >> imported. It does *not* have the timestamp of the original file. > Off the top of my head I can't think of a reason why this wouldn't be working > correctly. > >
