Julian Foad wrote on Fri, Mar 11, 2022 at 19:36:41 +0000:
> Stick with the idea, for now, that we do need to handle that "restore"
> part of update.
Can we deprecate it?
In the API, create an svn_client_updateN() function that's documented to
be like svn_client_updateN-1() but without reverting absent files. In
the CLI, create an «svn update2» command with the same caveat. Tell
people who use pristines-on-demand to use «svn update2» rather than «svn
update». Would this work?
> The alternative approach is to add a callback to the
> lower level "get the pristine" function that it uses. Then it would be
> able to fetch what it needs when it needs it and not fetch anything it
> doesn't need. Evgeny cautions us about that alternative approach, but
> *in principle* if we could get the protocol level behaviour absolutely
> right, that would (I think) surely be better.
>
> That "restore" happens, within update, before the server tells us
> whether any update of that particular file is actually present on the
> repository. (Perhaps it could be moved to afterwards; I haven't
> investigated that possibility.)
>
> Then, never mind whether we care about supporting that "restore" thing;
> because next a similar pattern applies to the "normal" part of the
> update (everything it does after "restore"). Obviously we need the
> normal part of update
Yes, but for the "deltas" part of update we already mostly DTRT, don't we?
- If the file is not modified, the WORKING file doubles as an on-demand
BASE (it gets detranslated when BASE is called for) so hydrating it is
a no-op.
- If the file is locally modified, then by design, we need to end up
with a pristine for it. Right now we'll download BASE, and then
download a delta to the new BASE and do a 3-way merge. Can we avoid
downloading either the old BASE or the delta?
There are three possible cases (cf. merge_file_trivial()):
+ the old and new BASEs are equal, in which case the delta download
and application is O(1), and the BASE download is fine because
a modified file is _supposed_ to have a pristine; or
+ WORKING and the new BASE and are equal, in which case we will
download stuff we don't need to (but this is an edge case); or
+ we need to run a three-way merge, which means we need the
.rN .rM .mine all handy. We have only one file, so we need the
server to send us the other two, and the question is just whether
the delta from .rN to .rM would be applied client-side or
server-side. The .rN .rM .mine files might be merged by us with
a 'G' notification, or we might give up and throw a 'C' notification,
but we can't avoid downloading two of the three files — unless
someone knows an rsync-like way to do diff3 on three files when two
of them are not locally available.
Users can avoid this case by using svn:needs-lock on these large
files, to ensure the old and new BASEs will be equal. Cf.
https://mail-archives.apache.org/mod_mbox/subversion-dev/202201.mbox/%3C20220131115758.GA14771%40tarpaulin.shahaf.local2%3E
So, it seems to me we're doing what we can except in the case of an
update that would make the new BASE identical to WORKING; and should
recommend that users consider svn:needs-lock. What am I missing?
> > [...] From my laymans point of view, we have a database in
> > the WC that says what we have. I assumed we largely would be using
> > that information when talking to the server about what it needs to
> > send us to do an update.
>
> Well, yes and no in the current two-phase (hydration, then operation)
> approach.
>
> > So I am just not getting why the server needs
> > to send us a file that WC already has.
>
> It doesn't ever send us a file that the WC already has. The issue we're
> concerned about is it sending a pristine that is (knowingly) absent from
> the pristine store, but for a file whose pristine is not going to be
> looked at during the current update. It might be needed by some future
> operation but the current approach fetched it pre-emptively (by design)
> but for this use case we would rather not do that.
>
> > I know your answer will be the "restore situation" [...]
>
> That's not the essential part, no; the main part of "update" is
> obviously the essential part, and it has similar characteristics and
> options, and isn't optional.
>
> - Julian
>
