Daniel Shahaf wrote:
> Julian Foad wrote on Fri, Jan 21, 2022 at 11:15:04 +0000:
>> I'm concerned about the implementation scanning the whole subtree,
>> calling 'stat' on every file [...]
>> Don't we already have an optimised scan for local modifications
>> implemented in the "status" code?
>  
> This? — [subversion/libsvn_wc/status.c]
> [...]
>  
> This still does a stat() on every file; how else would it obtain
> dirent->mtime?  It doesn't do open()/read()/memcmp().

The main point is DRY: maintain exactly one implementation so that both
the precise functionality and the performance optimisations are shared.

An example of the sort of thing the optimised code *could* potentially
do would be to obtain the mtimes of all the files in a directory in one
single read-dir call, depending on APR/OS/FS details.

TODO: deduplicate this walker.


>> Premature Hydrating
>>  
>> The present implementation "hydrates" (fetches missing pristines) every
>> file within the whole subtree the operation targets. [...]
>  
> Does it?  Looking at textbase_walk_cb(), it only sets REFERENCED to TRUE
> for modified files.  [...]

I meant it fetches missing pristines that are deemed *wanted*, for all
files within the tree. That limits it to modified files only, but all
modified files (that don't yet have their pristines) not just those that
will be touched by the operation.

> However, in cases such as «svn diff --diff-cmd=<GUI tool>», fetching the
> pristines (too) close to the time they are needed could result in having
> to reopen RA sessions.

What would be a problem with that? How is it different from existing
long-running diff scenarios?

- Julian

Reply via email to