Replying to selected points from the last few messages. Daniel Shahaf wrote: > Julian Foad wrote on Thu, Jan 20, 2022 at 21:03:02 +0000: >> The only case in which a simple per-WC setting might be unsatisfactory >> is the following combination: > > Why would it be the only case?
I assert that per-WC control suffices if any of the conditions I listed is false. > [...] >> - 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 > > Disagree. Why would fetching on-demand being a problem _necessarily_ be > caused by an "often enough" need to work on some files? Why couldn't > on-demand fetching pristines be a problem for files that change once in > a blue moon? We agree. If even once is a problem in a particular case, then once qualifies as "often enough" in that case. Maybe my wording or my lower limit wasn't clear. > For example, [...] some files that are large and diffable and > may need to edited and diffed while behind a narrow downlink. Yes, this is an example of the case I am describing where a simple per-WC setting might be unsatisfactory. >> - that subset of files is not "huge" in total; and > > I agree that that subset's pristines are necessarily able to be stored > locally at least from time to time, but no more than that. It's not > _necessarily_ posssible to store those files' pristines permanently [...] You rightly point out that cases may exist where the pristines-wanted subset is only needed some of the time, and the rest of the time it's important to recover that space for other uses. That implies the pristines-wanted subset is "huge" -- otherwise by definition the space they occupy would not be unacceptable to store permanently. When you need those pristines, it would therefore be OK to disable pristines-on-demand for the whole WC, because that isn't hugely worse than if you could choose just the subset. (Saving a minority of the pristines space is not a driving requirement for this feature, even if it would be nice to have.) In those cases, switching the WC between pristines-present and pristines-on-demand would be necessary. Such "switching" is probably a strong requirement anyway, even outside this case, as I should think it would be considered poor UX if it were not possible to change one's mind without a re-checkout. >> - that subset of files can be distinguished from the rest by metadata. > > Why is this necessarily the case [...] this seems to rule > out solutions that involve hardcoded lists (à la svn:ignore [...] I meant any sort of metadata including such lists, but basically you're right that this is not really relevant to describing the use case. > Let me try to sketch a use-case for wanting only _some_ files to be > pristineless. [...] I don't dispute that some cases exist where it would be nice to have per-file control. I still see it as merely "nice" and still do not see how it could be considered essential or very important. It's not completely clear to me what you mean to draw out in your 'libsvn*.so' example. It seems to be a case where the user wants efficient 'commit' of a few files which are large enough to care about that operation (let's assume they are diffable enough for their pristines to be useful) -- but make up only a small subset of the total WC size so omitting pristines of the majority of the WC, which is huge, would be important to save space. Yes, that's a case where subset control would be nice. But I would argue to that case, there are alternative and even better solutions than managing pristines. The user could make the WC shallow instead, omitting the pristines *and* working files of releases branches they don't currently need to work on while behind the narrow downlink. Or they could have their main WC pristine-less and check out a separate WC, with pristines, containing just the minority parts that they need offline. > Which brings me to a less contrived / more general point: What if the > user _knows in advance_ they'll need a pristine? Shouldn't there be: — > > - a way to say "I'm about to change a large, diffable file; detranslate > it into the pristine store before I touch it"? Perhaps even make > files read-only at the OS level (as with svn:needs-lock) [...]? > - a way to say "[...] download a pristine for this file now"? > - «svn commit --keep-pristines» [...]? At one level these are some logical extensions to the control that users would have over the pristine-management process. These additional controls might be valuable in certain cases. In the context of the main driving use cases (fast connectivity to the repo) these would be marginal tweaks with no real benefit. They could have real benefits in the scenarios that we looked at above where there is neither plenty space nor plenty connectivity, and when per-file control of pristines is available. We should consider making sure the API exposes these operations to keep/fetch/store pristines so that they could potentially be added to the UI of clients later. The 'svn' client would not necessarily ever want to expose this degree of control: it's likely too much to add to the user's cognitive load. It seems more something that certain scripts and clients built for automation tasks might benefit from, so might make sense just in APIs and bindings. - Julian
