On Mon, Jan 31, 2022 at 6:41 AM Johan Corveleyn <jcor...@gmail.com> wrote: > > 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.
+1 to avoiding the double negative. I did previously speak in terms of the (pristines-on-demand) feature being turned on or off, but I was thinking from the perspective of a proposed new option which shouldn't take effect unless the user opts in. Imagining it from the perspective of a future user after the feature exists, this is a double negative and is indeed confusing. More inline responses below... > 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. +1. Since pristines are part of a particular working copy, the variables that indicate whether they are present and how/when they are fetched should be part of the working copy as well. > 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. That would be convenient; if a user wants pristines-on-demand all or most of the time, this would save having to specify that for every checkout. Is it mandatory for the first iteration? I don't know, but I do think it would be very nice to have. What *is* mandatory in my mind is an option for 'svn checkout'. The user should not be locked in to a configured default because they may (and perhaps are even likely to) have a mix of different repos they checkout, perhaps from faster or slower servers, or perhaps some repos with seldom-changing and others with frequently changing ones, etc. The user knows which is the more common case and should configure that as the default, then override it at checkout time for the less common case. Cheers, Nathan
