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