On Fri, Mar 30, 2007 at 08:56:57AM -0400, Daniel Berlin wrote:
> On 3/30/07, Malcolm Rowe <firstname.lastname@example.org> wrote:
> >On Fri, Mar 30, 2007 at 03:49:28AM -0400, Rick Yorgason wrote:
> >> You are missing something Rick. That doesn't make sense at all. If you
> >> could convert a 1000k window into 10 100k windows then we wouldn't have
> >> this problem at all, dummy.
> >Really? It sounded fine to me - where's the problem?
> Translation is relatively easy for xdelta (though it may result in
> space expansion, so you won't quite end up with 10 100k windows.
> Among other reasons, zlib(500k of instruction data) != zlib(100k of
> instruction data) + zlib(100k instruction data) ...
Ah, we can't refer to sources outside of our window, so we'd need to
fully reconstruct the 1000k window and then re-delta to produce each
100k sub-window, right?
However, that does neatly sidestep the problem of target copy operations
> So it's certainly not impossible to make this backwards compatible by
> window size chunking, but I wouldn't want to be the one to implement
> that. IMHO,, you are better off just making an svndiff2 with explicit
> window size and doing what we did for svndiff1, which is have
> client/server tell each other capabilities, and use repository format
> to say which svndiff version to use.
Right, though it's a little harder because we can't transcode svndiff2
to svndiff1 as easily as we could for svndiff1->0 (we just decompressed
the data section, IIRC).
Received on Fri Mar 30 15:40:54 2007
- application/pgp-signature attachment: stored