[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-02-10 17:17:57 CET

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

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.