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

Re: Making blame even faster

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-02-10 17:06:42 CET

On Thu, 2005-02-10 at 10:48 -0500, Mark Phippard wrote:
> cmpilato@localhost.localdomain wrote on 02/10/2005 10:43:40 AM:
> > Branko Čibej <brane@xbc.nu> writes:
> >
> > > The more I look at your numbers, the more it seems that xdelta is a
> > > better choice. The worse compression seems to be balanced by better
> > > performance, which makes sense. Unless I've done something really
> > > stupid in vdelta or the combiner, we should probably look switching to
> > > xdelta in 1.2.
> >
> > +1.
> Doesn't it require a dump/load though? I thought that means 2.0.

No, it doesn't.

The output of both vdelta/xdelta is converted into a binary diff format
known as svndiff.
That is what is in your repositories, and sent over the wire.

Both of them generate valid svndiff, and the delta applier can apply all
valid svndiff's.
So nothing notices.
IE It's just the actual operations that are in a given svndiff that will
Before you might have (human version of the svndiff):

copy from source 0, 50 bytes
insert new data 4 bytes, "blah"
copy from target 4 bytes

with xdelta you might have
copy from source 0, 50 bytes
insert new data 8 bytes, "blahblah"

Of course, your repo will still have svndiff generated by vdelta (which
can trigger the bad behavior in the combiner) unless you
dumped/reloaded, but it would still function fine.

The same is true of all clients and servers. A server could be giving
you svndiff generated from vdelta, and you could send it back svndiff
generated by xdelta, and neither would be any the wiser.

It's good that we didn't directly send xdelta/vdelta results over the
wire, and actually convert it to an intermediate format, because it
allows us to do this type of change without backwards compatibly


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 10 17:10:12 2005

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.