On Fri, Mar 11, 2022 at 10:24 AM Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > > Julian Foad <julianf...@apache.org> writes: > > > Conclusions: > > ------------ > > > > It is certainly possible that we could modify "update" and the other > > "online" operations, at least, and the previously "offline" operations > > too if we want, to make them fetch pristines at point-of-use in this way. > > > > Such modifications are not trivial. There is the need to run additional > > RA requests in between the existing ones, perhaps needing an additional > > RA session to be established in parallel, or taking care with inserting > > RA requests into an existing session. > > I think that this part has a lot of protocol constraints and hidden > complexity. > And things could probably get even more complex for merge and diff. > > Consider a bulk update report over HTTP, which is just a single response that > has to be consumed in a streamy fashion.
Feel free to ignore this question because it is not going to help us get to a solution, but there is something about all of this I do not understand. Today, in normal SVN, if I do svn update my assumption is the client and server negotiate a fairly efficient reply. The server only sends the client the data it needs to update. Maybe I am wrong, but I do not feel like I am. This is where the question comes in ... why does not having the pristines change this? The WC still knows what files it has and what revisions. Isn't this what drives the process? I just do not understand what has changed that forces the server to send the client the version of a file that the client already knows it has. Mark
