Daily Use Guide - cleanup

[Jens Wilhelm]

I think the description in  https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-cleanup.html under Fix time stamps is not correct.

As described in https://subversion.apache.org/docs/api/latest/group__Cleanup.html the meaning of this option is:

If fix_recorded_timestamps is TRUE, this function fixes recorded timestamps for unmodified files in the working copy, reducing comparision time on future checks.

This option doesn't change any timestamp of the files in the working copy. It does change the entries in the pristine database instead. A changed timestamp of an unchanged file will be stored into the field last_mod_time in the NODES table.

In some cases this can has an effect to performance. 

[Alexander Stohr]

If i understood "recorded timestamps" correctly, then /recorded/ means at the last real svn driven file update a copy of the real time stamp is written to the local database state so it can be compared at a later time.

For the unix file systems realized time stamping of creation, modification and access times the item in question is most probably the modification time. The Win32 platforms are using a very similar sheme for already a long time on many everyday file systems.

[Jens Wilhelm]

Yes, modification time of a file is stored to the local database either by an update or a commit changing the state of the file. If the timestamp of the file is the same as stored in the database, there will be no file comparision on estimating modifications of the file. For some files I have to store filestamp as a property and I adjust this by a post_update hook script. To avoid time consuming file comparisions on large binary files I have to fix the timestamps in the database by a cleanup. 

So I think this behavior has nothing to do with the time of the last commit as meantioned in the documentation.

[Stefan]

I've changed the docs in r28502