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

Re: [PATCH] Replace vdelta with singel insert op

From: Branko Čibej <brane_at_xbc.nu>
Date: Sun, 27 Jan 2008 13:17:01 +0100

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.

> 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.

-- Brane

---------------------------------------------------------------------
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 13:17:28 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.