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.
Received on 2017-07-28 14:17:55 CEST