Thanks for your replies, Evgeny. Replying to the "status walk" part.
(TL;DR: Could we optimise by doing the db scan before the stat?)
I think we want to ensure, as far as possible,
- no significant performance degradation if user does not opt in to
the new feature;
- overhead when enabled sh
Julian Foad writes:
> We could swap the scanning logic around to do the (quick) check for
> missing pristines before deciding whether a (slower) file "stat" is
> necessary. Positives: eliminates the redundant "stat" overhead which may
> be significant in working trees containing many files. Negat
The attached patch is a WIP/debug patch, against 'pristines-on-demand'
branch, sketching how a 'pristines-mode' setting can be set:
- in the user config (~/.subversion/config)
- and/or in a new per-WC config (wc/.svn/config)
each with the same syntax ('[working-copy]' section, 'pristines-mode
Julian Foad writes:
> SEMANTICS
>
> The user can choose one mode, per WC, from a list of options that may
> include:
>
> - off: as in previous versions, no checking, just assume all pristines
> are present
> - pristines-on-demand: fetch "wanted" pristines; discard others
> - fetch-only: fet
On 2022-01-27 17:21:42 +, Julian Foad wrote:
> This setting doesn't have to be persistent in the WC. It could be
> configured in client run-time config instead (e.g.
> ~/.subversion/config), as we previously mentioned.
>
> If it's stored in the WC then we need to create some new UI to control
5 matches
Mail list logo
