[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Performance bug? Very large rev files

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-03-30 15:40:24 CEST

On Fri, Mar 30, 2007 at 08:56:57AM -0400, Daniel Berlin wrote:
> On 3/30/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> 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).


  • application/pgp-signature attachment: stored
Received on Fri Mar 30 15:40:54 2007

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.