Replying to a few different points in this thread. On Jan 27, Julian Foad wrote: > 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: fetch any pristine that's absent; do not discard
I think, whatever the name of the property here, "off" is confusing for wanting all pristines (the back-compat / old / default (?) behaviour). To me it sounds like I am setting the feature "do not fetch all pristines" to off, so "please fetch all pristines" with a double negation. Maybe we should go for something like: pristine-fetching = full (or "eager", or "all", i.e. default) | lazy (or "on-demand") Perhaps with a third option "lazy-keep" (like your "fetch-only"), indicating on-demand, but not immediately cleaning it after use (don't know if this would be useful -- could be added later of course). Or "lazy-transient" for the "lazy with immediate cleaning after use" as opposed to "lazy" (which keeps fetched pristines once fetched). On Sat, Jan 29, 2022 at 9:22 AM Julian Foad <julianf...@apache.org> wrote: > > Vincent Lefevre wrote: > >> [...] Specifying a pattern to match the WC path [or] per repository [...] > > > >But what if a WC can be accessed from different machines [...]? > > Then: > - The config option should be designed never to assume or depend on the > pristine store being in a particular state (such as fully populated). > - The user might want different behaviour on different machines, or the same > on all. > - The patch I posted yesterday in a separate thread allows the user to set > the config option in the user config or per-wc config. > - I noticed we already have some other config options in the '[working-copy]' > config section. We probably should allow the user to set those per-wc too. > - Julian Hmm. I think the pristine-fetching strategy that is chosen for a particular working copy should a property of that working copy. That's because it has a "persistent" impact on that working copy. Changing that strategy (if we would support that) severely impacts the disk layout of that particular working copy. It's not just a runtime thing, like using "exclusive sqllite locks" or some such (leaves no trace for the next user). If it would be a runtime setting, and Alice and Bob would both work on the same working copy, and the former has "pristine-fetching=full" and the latter "pristine-fetching=lazy" (or some detailed strategy with patterns, whatever), the working copy would be changed severely every time one or the other touches it. So I think the chosen pristine-fetching strategy for a working copy should be stored in the WC itself, probably in wc.db. However, we would still need related runtime config options. But I see them as "defaults" for when creating a new working copy. Perhaps these belong in a [working-copy defaults] or [working-copy creation] section, as opposed to the [working-copy] section which is more about runtime behaviour. Basically: - The chosen pristine-fetching strategy should be a persistent property of the WC, to be chosen at creation time. - Defaults for this should be part of our runtime-config area (and perhaps also options for 'svn checkout'). - We might introduce ways to change the setting of a given WC (but it's not a must have for the first iteration, I guess) On Fri, Jan 28, 2022 at 6:11 PM Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > > Julian Foad <julianf...@apache.org> 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. Negatives: some > > re-work needed in the current implementation. > > > > Of these, the last one currently looks viable and useful. > > > > Does that one look promising to you? > > I might be missing something, but I don't yet see how we could save a stat(). > > Currently, a pristine is hydrated if and only if the corresponding working > file is modified. Let's say we check if a pristine is hydrated beforehand. > If we find out that pristine is dehydrated, we have to stat(), because if the > file is modified, then we need to hydrate. If we find out that pristine is > hydrated, we still have to stat(), because if the file is no longer modified, > then we need to dehydrate. What seems important to me is that, if a WC is set to pristine-fetching=full (or SVN 1.15 would be working with an older working copy, without the "pristine-fetching" property (say if upgrading of the wc format would not be needed)), that the code here can assume (like the old code) that the pristine is present. No need for an extra stat, just assume it is there, if not, error out like today (incidentally, this is a very annoying error to run into (if a pristine is accidentally deleted for some reason), because a user cannot recover from it, the WC is hosed -- but that is another issue). So we introduce no extra overhead for "fully fetched / old style" WCs. Of course, keeping the extra overhead as low as possible for "pristine-fetching=lazy" WCs is an important consideration too (but I'm afraid I can't contribute anything useful there :-), haven't dug in deep enough). -- Johan
