Wow, Daniel. Thanks for that excellent explanation!
/me calls it a day, having already learned something (and so early!)
Daniel Berlin <dberlin@dberlin.org> writes:
> > 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:20:48 2005