[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1803140 - in /subversion/trunk/subversion: include/svn_delta.h libsvn_delta/svndiff.c tests/libsvn_delta/random-test.c

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Fri, 28 Jul 2017 15:17:24 +0300

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> I did misunderstand the relation between the two streams, …
>
>> The internal buffer doesn't grow beyond the (header size + max window
>> size in svndiff format), which is O(1).
>
> … but I still don't see why this statement is true. The stream is
> written to by [a callback provided by] svn_txdelta_to_svndiff3(), and
> that function does not promise to write into the stream one svndiff
> window per call. The API contract permits it to write into the stream
> more than one svndiff window per call, in which case the buffer's size
> will not be O(1).

I don't see any real issues with relying on the implementation detail (how
the window_handler() function works) of the API from the same module.

Perhaps, I could add a couple of comments on this.

To avoid this kind of coupling altogether, we could implement the alternative
approach from my previous e-mail. Which is, provide a read handler that
emits the svndiff header, calls encode_window() per every txdelta window
and keeps the part of the encoded window that the caller can't accept at
this time, thus postponing it to the next call of svn_stream_read(). But, in
the meanwhile, I don't think that such implementation is currently required.

Regards,
Evgeny Kotkov
Received on 2017-07-28 14:17:55 CEST

This is an archived mail posted to the Subversion Dev mailing list.