Karl Fogel wrote on Tue, Mar 08, 2022 at 17:59:20 -0600: > On 08 Mar 2022, Daniel Shahaf wrote: > > 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. > > Well, depending on the context, I may be using the word "pristine" flexibly. > Sometimes I mean a literal integrated-into-wc-metadata pristine, and > sometimes I just mean "an extra copy of the file, that the user has made > locally". >
I see. > (It's possible that the degree of precision you would like in this > sub-discussion is not one I'm willing to adhere to consistently :-). I > can't always predict what will matter to a given interlocutor. But I'll try > to be sufficiently precise in my responses below at least.) Thanks, Karl. I hope I'm not frustrating you. I do try to be interoperable with as many interlocutors as possible, but using "foo" to sometimes mean "bar" and sometimes mean "poor man's alternative to bar" does in fact create ambiguities. > > 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? > > Yes, thanks for the suggestion, and I agree. I would love for MVP or MVP+1 > to have an explicit "rehydrate" UI. I think there *might* be some value to > shipping MVP without such a feature, in order to first get some real-world > experience with how people use pristine-less working copies, before we make > long-lasting UI decisions. > > But anyway, +1 to the general idea. Filed: https://issues.apache.org/jira/browse/SVN-4894 > > 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. > > Users can already copy files behind Subversion's back, of course. > > I'm worried that implementing 'svn x-hydrate' commands now would be > premature -- we don't know enough about real-world usage yet. I'd feel more > comfortable putting out one release (of x-hydrate-less MVP) to get feedback > on pristine-less working copies. We could even say that we're considering > adding x-hydrate commands but that we're waiting until the next release so > we can make sure our UI ideas match people's actual needs. > > Anyone else have thoughts on this? > Just to make sure you noticed I'm proposing this as an x-* command, i.e., without promising it'll behave in 1.16 as it does in 1.15, or even exist at all in 1.16? We could write a Python script to explicitly hydrate something, even after 1.15.0-GA, to let people experiment with that to some degree. (It won't preserves hydration through commits, of course.) > > 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. > > Yes, that's a good point (in that last paragraph there), and we should take > it into account when (re)implementing commit logic. Filed: https://issues.apache.org/jira/browse/SVN-4895 Cheers, Daniel
