On Mar 11 2022, at 5:07 pm, Mark Phippard <markp...@gmail.com> wrote:
> 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. [...]
Correct.
> 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.
My best recent explanation I can offer was in my reply about 5 messages
ago, at 10:36 UTC, with subsections "Restore is an aberration" and
"Merge". Not sure what exactly you're missing; maybe not seeing the
overall difference between the two approaches that are currently being compared?
- Julian
