RE: svn_client_status5 veeeeeeery slow [SEC=UNCLASSIFIED]
From: Thamm, Russell <Russell.Thamm_at_dst.defence.gov.au>
Date: Sun, 30 Jul 2017 22:56:17 +0000
Thanks very much.
On Fri, Jul 28, 2017 at 6:20 AM, Thamm, Russell <Russell.Thamm_at_dst.defence.gov.au> wrote:
The reason is that the "lastModified" times in the svn metadata (inside .svn/wc.db) are different from the "lastModified" times of the files on disk. Probably because of the CD transfer (copying files over different volumes often resets timestamps on files on the filesystem).
'status' has an optimization to assume the files are unchanged when both filesize and lastModifiedTime are unchanged. If either filesize or lastModifiedTime are different, svn has to read the entire file and checksum it.
You can fix the situation by running 'svn cleanup' on the slow working copy. This will correct the lastModifiedTime's in the svn metadata to correspond to the on-disk state. It may also be possible to transfer the files with precisely keeping the original lastModifiedTimes (maybe with some copying options), then the working copy will still be optimized after the transfer. But it depends, it's also possible that the target filesystem cannot represent the same granularity of lastModTimes as the original one.
-- Johan IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.Received on 2017-07-31 00:56:42 CEST
This is an archived mail posted to the Subversion Users mailing list.