Daniel Shahaf wrote: >> The request is to break the original design's invariant for this case. > > By only hydrating files that have been updated repository-side. How > will small, modified files that _haven't_ been remotely modified get > hydrated, then? The logic is the same for small and large files, IIUC.
They will get hydrated by any operation that needs them to be, such as diff and revert. > Also, why is this specific to «svn update»? It's not specific to update. Update is a particular case that Karl cares about so I looked at doing "update" first. Implementing this approach in one subcommand at a time could be considered releasable incremental steps, because each one is a further optimisation. > It seems to apply equally > well to «svn diff» without further arguments, since the "large" files > are presumed to be undiffable, That's not presumed. It's a rule of thumb that large files are often undiffable, but as yet there has been no plan to omit them from a requested diff by default. That could be a future sub-feature. > If the issue does apply not only to 'update' but also to 'diff', that > suggests we should look for a solution that applies to both of them > (e.g., exclude "large" files from being recursed into by default, or > make it so "large" files _never_ get hydrated). That is a possible alternative to consider. Perhaps even a good one worth filing and discussing further. - Julian
