Re: svn_client_status5 veeeeeeery slow [SEC=UNCLASSIFIED]

On Fri, Jul 28, 2017 at 6:20 AM, Thamm, Russell
<Russell.Thamm_at_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