On Fri, Mar 11, 2022 at 9:17 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > If possible and not overly burdensome, I think it would be a good > thing to keep the "restore" functionality for the following reasons: [snip]
I agree. I know about the restore feature too, and am used to it. Also, I think it would be a mistake to create different behaviour between "normal (pristine-full)" and "pristines-on-demand" working copies. On "update's essential functionality": the main problem, I feel, is that the current implementation fetches missing pristines for modified files *even if they will not be updated*. I understand that this happens because, at the point of "textbase-sync" (check for and download missing pristines, which happens before the operation goes into details), it doesn't know yet which files will effectively receive an update. So this really feels like a waste (fetching stuff which will not even be needed, and indeed in many use cases like Karl's often won't be). But you all know that already, I guess, and I appreciate all efforts in trying to come up with creative approaches to avoid this "waste" :-). Don't know if this is realistic or useful, but: Apart from pushing this textbase-sync closer to the point of access, one could imagine that during textbase-sync the client would already have more information about what will be updated later on. For example by organizing the client-server exchange so that the client first receives a report, without texts, about what will be updated, then fetching missing pristines if needed, and then going on to request the actual update texts. IIRC, this kind of exchange is already the default since 1.8 with serf (except if certain directives / config flags are set) [1]. Then again, it might be quite awkward to implement this kind of flow only for one particular variation of our client-server protocol. [1] https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default -- Johan
