On Thu, 2006-02-09 at 22:45 +0100, Molle Bestefich wrote:
> I wrote:
> > (The difference between the filesystem's state at commit time for
> > commit 1 and 2 is that I've run "emerge --sync" and "emerge -D world",
> > applying one week's worth of minor OS updates to the filesystems..)
>
> Just to rule that bit out of the equation, I did two tar/gzip runs in a row.
>
> /repos/repos/test1/db/revs/:
> total 2344672
> -rw-r--r-- 1 nobody nogroup 115 Feb 6 08:09 0
> -rw-r--r-- 1 nobody nogroup 786399319 Feb 6 08:31 1
> -rw-r--r-- 1 nobody nogroup 806034124 Feb 10 00:53 2
> -rw-r--r-- 1 nobody nogroup 806134424 Feb 10 01:55 3
>
> /repos/repos/test2/db/revs/:
> total 1927032
> -rw-r--r-- 1 nobody nogroup 115 Feb 6 08:09 0
> -rw-r--r-- 1 nobody nogroup 697837468 Feb 6 08:44 1
> -rw-r--r-- 1 nobody nogroup 636746962 Feb 10 01:08 2
> -rw-r--r-- 1 nobody nogroup 636746967 Feb 10 02:10 3
>
> Ack.
>
> Curiously, I have a 300 MB filesystem which changes a little now and
> then, it seems to work better there.
>
> Is there perhaps some sort of size limit built into the delta
> algorithm, or am I just trying to do something atrocious?....
>
It is a window size of 1 meg at a time.
So if nothing matches within that 1 meg window, you are out.
My guess is that because you are not sorting in an order where new files
appear last, the tar gets thrown off by more than the window size and
nothing ever matches.
---------------------------------------------------------------------
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:28:19 2006