UNCLASSIFIED Thanks very much.
-----Original Message----- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Friday, 28 July, 2017 7:13 p.m. To: Thamm, Russell Cc: users@subversion.apache.org Subject: Re: svn_client_status5 veeeeeeery slow [SEC=UNCLASSIFIED] On Fri, Jul 28, 2017 at 6:20 AM, Thamm, Russell <russell.th...@dst.defence.gov.au> wrote: > UNCLASSIFIED > > Hi, > > > > svn-win32-1.88 > > > > I am not subscribed to the mailing list and would appreciate being > cc:ed in any response. > > > > I have a service that uses svn_client_status5 to determine the current > state of a subversion working copy. Even though I have several > thousand files in the working copy, this normally takes a few seconds. > > > > However, on one particular PC, this takes several minutes. This > particular PC doesn’t have access to the repository – the working copy > is transferred via CD. However, my laptop doesn’t have access to the > repository when it’s not connected to the network and it doesn’t exhibit this > problem. > Furthermore according to WireShark, the software is not trying to > access the repository. > > > > Using sysinternals procmon, it appears that every single file in the > working copy is accessed on the problem PC, but only modified files > are accessed normally. > > In both cases, the directory tree is scanned (apparently in search of > .svn > directories) and many accesses are made in the .svn directory > (especially ws.db). > > > > Consequently procmon reports 416,177 file system events on the problem > PC vs > 30,068 on another normal PC. > > > > My call is: > > > > svn_error_t *err = svn_client_status5(NULL, context, path, &rev, > svn_depth_infinity, true, false, false, true, false, NULL, > statuslist_walk_cb, this, pool); > > > > Any idea why svn_client_status5 is behaving so strangely? 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.
