[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: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2007-03-30 14:56:57 CEST

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) ...

Second, translation is going to be quite annoying for vdelta generated
deltas, due to target side operations. We don't have a way of
specifying negative offsets, so i don't believe there is a way to say
"this is a target side copy of stuff 50 bytes before my target window
You will have to transform these into new data or source copies, which
is going to be a size expansion.

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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 30 14:57:12 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.