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

Re: svn binary deltas: can they be tuned or sth?..

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2006-02-09 23:06:12 CET

Malcolm Rowe wrote:
> > As you can see, Subversion's delta algorithm doesn't really work as I
> > had expected it to :-).
> > Any clue as to why?
>
> A couple, but nothing significant:
>
> Is the file ordering the same in each tarfile?

Why wouldn't they wouldn't be?
It's tar'ing up an ext3 filesystem - would the order change between two reads?
(I tried to find a sort option on --tar, but seems there is none..)

> Did emerge do anything silly like update the mtime for each file?

Heh, probably :-).
It does an rsync of about 60.000 files.
As per my follow-up, that doesn't seem to be the problem though.

(On a side note, it would be nice if Portage used Subversion to store
those files instead. That way you'd have a clear picture about how
updated your system is, since it would match a given revision number.
Not sure how effective Subversion's transfer mechanism is compared to
rsync though..)

> At what points is gzip resync'ing? It's possible that there isn't as
> much commonality between the files as you'd expect.

Not sure I understand the question.
It's gzip 1.3.5 with gentoo's rsync patch:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-arch/gzip/files/gzip-1.3.5-rsync.patch?rev=1.2&view=auto
which has a # define RSYNC_WIN 4096, is that what you mean?

Maybe Gentoo's gzip is just defective wrt. --rsyncable?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 9 23:07:06 2006

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.