Daniel Shahaf <d...@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
