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.
>
>
Received on 2012-01-25 21:39:37 CET