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
change.
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
problems.
--Dan
---------------------------------------------------------------------
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