Re: [Gnu-arch-users] a brief note on "delta compression"

[Robert Anderson]

--- Original Message ---
From: address@hidden (James Blackwell)
To: address@hidden
Subject: Re: [Gnu-arch-users] a brief note on "delta compression"

>>> My personal hunch is that the proper X is right around 5.
I've got no
>>> actual proof for that, mind you.=20
>>
>> You've neatly oversimplified the problem :P
>>
>> The appropriate size for X is the jump which people want to
frequently
>> make. That's probably precisely the distance between each pair of
>> releases.
>
>Grin. I don't think I've oversimplied it. My unspoken point was
that we
>*don't* what X is -- we don't even know if there is an X on a
>practical basis. I threw out 5 because it seems to me that
whenever I
>update my working copy of somebody else's branch, there's always
5 or 6
>patches.
>
>The way to actually get X is to find the average rate that
developers
>commit patches, the rate that people replay/update their trees, and
>divide them out. Though, with enough effort, I could give an
answer for
>the first question, I don't think theres a way to get the second
data
>point.

I think the following idea has come up before:

How about something like N^m, where m is the minimum needed to
span the current revision space.

So with something like N=5, you'd have deltas between every 1, 5,
25, etc. as needed.  For N=5, you'd never be more than two hops
from the next delta resolution.  Seems like you could traverse
arbitrarily far in a relatively small number of steps that way.

Of course, now you'd need an algorithm that can figure out the
optimal path, and build forward/backward as needed to traverse it.

Bob