Re: svn commit: r9496 - in trunk/subversion: include libsvn_delta tests/libsvn_fs

On Mon, 2004-04-26 at 05:05, Tobias Ringstrom wrote:

> > So does this change get us closer to fixing issue #1789 ("win32 can't
> > display large 'svn diff'")? If so, it looks like something we can
> > backport to 1.0.3. Or do we have to wait for APR to fix the real problem?
>
> No, because while this change makes it possible to change the stream
> chunk size and the svndiff window size independantly, we cannot change
> the stream chunk size because it's a constant in the exported API, and
> as such might be used by other code to declare buffer sizes. If we
> change the value, we risk breaking binary compatibility somewhere. It's
> a tiny risk, but it's safer not to change it.

I'm trying to understand the risk here.

Suppose we release 1.0.3, which uses an internal constant to control
buffer-size for the 'svn diff' stream, rather than the public constant.

Are you saying that somewhere out there, somebody may have written an
application which explicitly depends on the public constant to affect
stream-buffer sizes?

If so, man, how annoying. Because deep down, I don't believe such an
app exists anywhere... and meanwhile hundreds on win32 users can't run
'svn diff' in their console half the time. :-(

I guess that means we'll have to wait for 1.1. Grrr, I hate these
clashes between theoretical purity (interface promises) and practical
reality.

Either way, is there any objection to scheduling this issue (#1789) for
svn 1.1? Seems very easy to do, and we need to make the fix available
ASAP. It's pretty embarrassing for svn, even though one could easily
put the blame on APR or Win32 itself.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 26 18:20:12 2004