Branko Čibej wrote:
> Niels Werensteijn wrote:
>> I'd like to know what the status of this patch is.
>>
>> So far I have seen only 1 argument against including this patch as is.
>> This is the fact that with this patch communication between old (pre
>> 1.4) servers and new clients (or vice versa) uses a lot more bytes,
>> during export or initial checkout.
>
> If you're referring to my comment, that wasn't a counter argument, it
> was just a statement of fact, and I don't see it as all that horrible.
Alright, my bad!
>> It has been proposed to update the api's, including a "output will be
>> compressed" parameter in several function calls, so that this patch is
>> only effective between new versions of server+client. This has also
>> been countered, with the argument that this has a major impact, only
>> to keep things smooth for the old versions of the server/client, for
>> operations that do not happen often (initial checkout/in, import and
>> export).
>>
>> So where do we go from here? What can I do to get this patch included?
>> Should I start making a patch with updated api's?
>
> I think it would make sense to explore the idea that we could still use
> vdelta to compress content we send to the client when that client
> doesn't provide us with a base revision to create a diff against. That's
> worse than zlib, but better if the client only understands svndiff0.
>
> I know this might involve an API change that's as invasive as the other
> proposed API change, but it would be worthwhile to take a look and prove
> that one way or another.
Okay, I'll take a crack at it soon. I think instead of the "will
compress" flag I should choose to send the svndiff protocol version,
which should can be used to infer more information.
Regards,
Niels Werensteijn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-27 18:36:25 CET