On Sun, Jan 27, 2008 at 10:35 AM, Niels Werensteijn
<n.werensteijn_at_student.utwente.nl> wrote:
> 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.
I've revisited this patch and done some profiling. It's giving me a
20% speedup on a large checkout on my server.
Note that the problems with it were just performances with old
repositories and clients. First, it would make repositories from
pre-1.4.x bigger. But this is less of an issue now, since we actually
have a 'svnadmin upgrade' command now and anyone who cares about merge
tracking would have used it already. Second, it would be slower with
pre-1.4 clients. But by the time 1.6 comes out, 1.4 will be over two
years old; it's not unreasonable to expect people to use it
(especially since this won't *break* pre-1.4 client, just slow them
down).
Any objections to commit Niels's patch?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
Received on 2008-04-17 01:52:23 CEST