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? Point by point: > - the repository is "slow" (and/or offline working is required); Agreed. This can be assumed so there'll be a use-case for pristinelessness for some files. > - and, in a single WC: > - the WC data set is "huge" (relative to local disk space) in total; and Ditto. > - 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? For example, a laptop could easily be sometimes behind a wide downlink and sometimes behind a narrow one. If most of the time there's a wide downlink, the user might enable optional pristines for most files, but they might nevertheless have some files that are large and diffable and may need to edited and diffed while behind a narrow downlink. > - 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, and the files themselves aren't necessarily small (people diffoscope(1) ISO files nowadays). > - that subset of files can be distinguished from the rest by metadata. Why is this necessarily the case whenever per-WC granularity wouldn't suffice? Actually, this seems to be a statement not about the _use-cases_ in which per-WC granularity wouldn't suffice, but about the _solution_ that would address those use-cases. More specifically, this seems to rule out solutions that involve hardcoded lists (à la svn:ignore without glob patterns, svn:keywords, and «svn depth --set-depth=exclude»). > To be clear, I'm not trying to pick nits; I'm trying to make sure that we don't make unwarranted assumptions. We might get a lightbulb moment from that. (E.g., that's basically how we realized we should deprecate --reintegrate, IIRC.) > Let me try to sketch a use-case for wanting only _some_ files to be pristineless. Suppose that: - We wanted to distribute libsvn*.so via an svn repository. - We were informed of a vulnerability and needed to commit updated binaries - The RM had to commit the updated binaries whilst behind a narrow uplink - The RM knew in advance they'd be behind a narrow downlink, but did not know in advance [a vulnerability would be reported and therefore] the binaries would need to be rebuilt and uploaded - The RM is usually behind a wide downlink In this situation, it would be reasonable and even prudent of the RM, before they leave their wide downlink, to pre-hydrate the bases for 1.10 and 1.10 binaries, only. This way they're prepared: they'll be able to rebuild and push 1.10 and 1.14 binaries should a vulnerability come in; and as to 1.13, well, that's no longer supported so it can wait until they're back at their wide downlink location. > 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) so the user doesn't modify the file accidentally until its pristine has been set aside? - a way to say "I've modified a large, diffable file and I'm about to go offline; download a pristine for this file now"? - «svn commit --keep-pristines», in case Alice has two logical changes that she'd like to make in separate commits? I realize that most of these ideas are more about the "large, diffable files; network access is slow/expensive" case and less about the "undiffable undeltifiable never-reverted large file; a 10Gbps connection to the server" case. > 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 starting with a per-WC knob. However, all else being equal, we should try to design this in a way that allows future extensions, including extensions that set pristinefulness on a finer granularity than per-WC. (That's similar to what I said earlier in this thread in [1]). Cheers, Daniel [1] <https://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3C20210730233846.GB23161%40tarpaulin.shahaf.local2%3E>, last hunk
