Karl Fogel wrote on Tue, Mar 08, 2022 at 14:01:22 -0600: > On 08 Mar 2022, Daniel Shahaf wrote: > > Karl Fogel: > > > Hmm, I don't see where I was assuming that the pristine would be > > > needed exactly once, though. Once the user has a local pristine > > > (by whatever means), > > > > To be clear, we're only talking about pristines that libsvn_wc knows > > about, right? As opposed to Alice running «svn cat iota@BASE» and > > saving the output somewhere. > > Hmm, I don't think I understand the question here. Can you ask it with more > details / context?
Sure. I was asking whether by "once the user has a local pristine" you meant a pristine — as in, a file under .svn/pristine/ that .svn/wc.db knows about and uses — or Alice making a local copy of the contents of file@BASE somewhere libsvn doesn't know about. > > > if she wants to keep that local pristine after committing its > > > corresponding working file, then she could do so or not do so, > > > depending on > > > whether she wants to continue paying the local storage cost for it. > > > > How would Alice keep iota's pristine after committing iota? «svn commit > > iota» deletes iota's pristine. > > Like I said, I wasn't going into UI details. Sure. Neither was I. > But if Subversion wants to offer a way for commit to keep the > post-commit pristine around (in circumstances where that file would > otherwise be pristine-less), it can do so. This wouldn't be for MVP, > of course; I'm just saying it's a conceivable feature and maybe some > day we'll offer it. +1 > For now, the way Alice would keep an "informal pristine" would be simply > manually copy the file. That's not a pristine in the full sense of the > word, but it will serve for local diffs and reverts of course. A manual copy of the BASE revision would "serve for local diffs and reverts", indeed, but I would hestitate to recommend this, because diff and revert are both core operations. If users need to reinvent these two wheels, then: - All the advantages of having just that one well-known «svn revert» button that all the users' GUI clients and scripts can press are lost - The local disk storage cost will be paid, but without all the benefits: e.g., commit will use a self-delta rather than a delta against BASE even if the file format does lend itself to binary diffs; ra_serf's ability to not download a file if the wc has another file with the same sha1 won't be used; the keyword-contraction and diff-ignore-content-type features of «svn diff» will need to be reimplemented; etc. - We might leave a bad impression on potential users As an MVP alternative, some sort of command to hydrate a single file, perhaps, as you have proposed? CLI-wise, I'll just say we might want to mark such a command as experimental (name it "x-foo" and document it has reduced forward compatibility promises). Backend-wise, we'll want to ensure a manually-hydrated file doesn't get dehydrated too soon. What's "too soon"? Until the user explicitly requests or permits dehydration. If hydration was manual, so should dehydration be. Makes sense? ---- The context of all this is whether 'update' should fetch pristines for modified files. I guess it should not do so by default (there's no reason to incur the costs, and the user has opted in to pristines-on-demand), but I don't think we should tell users to keep pristines _and not tell libsvn_wc about them_. The cost of implementing «svn x-hydrate» (however named) is smaller than the cost of asking users to reimplement core version control functionality. If we think there are use-cases in which users will want to have a pristine for a modified file, whether those use-cases involve «commit» or «diff» or «revert» or whatever else, then that pristine shouldn't be just the user's private copy of BASE; it should be a real pristine, live in .svn/pristine/ and be known to wc.db, and used for all svn operations, not just those the user has reimplemented. This way, by default «commit» will send self-deltas, but if the user wants a pristine for diffs or reverts, then reverts, diffs, and commits will all use the pristine. There shouldn't be any need for the user to reimplement their own pristine store and their own diff and revert operations. And yes, commit might not want to use pristines this way, but that's actually a separate feature request: a request to change the "When committing a change to a pristineful file, send a delta against BASE or a self-delta, whichever is smaller" logic, which IIRC works by computing a delta against BASE and comparing its length to the repository-normal filesize, to something that doesn't compute a delta against BASE in the first place. Cheers, Daniel
