On Thu, Jan 20, 2022 at 4:03 PM Julian Foad <jul...@foad.me.uk> wrote: > > Karl Fogel wrote: > >>> So if we have client-side configuration that can specify "no > >>> pristine" based on some combination of one or more of... > > [... size, properties, etc. ...] > > with a general mechanism for combining conditions, then things > > will be in a good position for future improvement. > > The more I think about this, the more I think we are prematurely > complicating the requirements in this respect. I'm going to back-track > and posit that a simple per-WC switch should suffice for the vast > majority of cases, and has the benefit of simplicity. (The user might > wish to set this based on the repository location -- local/fast versus > remote/slow.) > > I will note that I previously misunderstood the current > 'pristines-on-demand' implementation as fetching the pristine before a > diff (for example) and discarding it afterwards. In fact it keeps the > pristine as long as the file in question remains in a locally modified > state, and only discards the pristine when (before or after some client > operation) the file is no longer in a modified state. That is to say, it > fetches pristines less often than I had thought.
Thanks for explaining this. If I understand correctly, when pristines are turned off: The pristine for a given file is not fetched until the file is modified and an operation pertaining to it requires the pristine. Once fetched, the pristine remains present until the file becomes unmodified through either 'commit' or 'revert'. +1 to this. This seems more logical than immediate removal: if the file becomes modified and its pristine is fetched, then the user may (is likely to?) run additional operations requiring the pristine. No sense in re-fetching it several times in rapid succession. If users complain, 'svn cleanup --vacuum-pristines' could be made to just delete all pristines when the pristines-on-demand feature is active. While writing the above, it occurred to me that if the file is deleted, the pristine (if present) should be deleted as well. (Potential caveat: if the file is modified, subsequently marked for deletion with '--keep-local', and subsequently the user runs 'svn revert', the expected result is to restore the original contents as they appear in BASE.) More below... > The only case in which a simple per-WC setting might be unsatisfactory > is the following combination: > > - the repository is "slow" (and/or offline working is required); > > - and, in a single WC: > - the WC data set is "huge" (relative to local disk space) in total; and > - there is a subset of files on which the user needs to work > (requiring diffs, etc.) often enough that fetching their pristines "on > demand" is a problem; and > - that subset of files is not "huge" in total; and > - that subset of files can be distinguished from the rest by metadata. > > That is certainly a possible case, but we have no suggestion that it is > at all common. It is not one of the cases driving this feature. So I > think it is not something to design for at this stage. > > I'm going to work on getting something more basic (per-WC yes/no) closer > to production-ready and then we can re-assess it. +1 to this also. A production-ready per-wc on/off switch for pristines sounds reasonable to me for the initial feature and is arguably better than not-production-ready and full of bells and whistles. Cheers, Nathan
