> It is my understanding that in subversion the vdelta is generated on
> the client side, somewhere in libsvn_delta, and the server simply
> stores whatever the client gives it. Is that true, or does the server
> apply the vdelta and have both revs to look at and potentially
> recalculate the vdelta?
No, that's not true. The client must send the server a delta against
something the server already has. The server will use that original,
with the delta, to construct the new text. How the filesystem
actually stores these things is none of your business. :)
> One thousand years ago, when mainframes walked the earth, Walter Tichy
> made a big deal about how clever RCS was to store the most frequently
> requested version and calculate other versions relative to that one.
> Is subversion doing that? If so, it must have to calculate inverse
> deltas.
The first rev of the filesystem will indeed store the full text of the
most recent version of each node, and store older versions as deltas.
But in general, things don't need to be this rigid. All that matters
is that it can produce any revision somehow. The filesystem could
store the N most recently accessed node versions in fulltext, and
switch things between fulltext and deltas to reflect access patterns.
It could even cache recently computed deltas, to spit them out
directly to clients without recomputation. When you've got an
append-only data structure, they're easy to cache.
> The reason this comes up is that we're talking about cvs2svn
> outputting XML that includes a vdelta. I'm wondering if I can get
> lazy and just write a vdelta that says, "replace the whole file with
> this whole new file", without bloating the database.
But you should be able to use Branko and Greg's code to generate real
vcdiff data. Why would you need to generate trivial deltas?
Received on Sat Oct 21 14:36:09 2006