Introduction to history deltas
Johan Rydberg
jrydberg at gnu.org
Wed Dec 7 08:26:00 GMT 2005
Jan Hudec <bulb at ucw.cz> writes:
>> Note that the idea with knits are that you do not fetch the whole
>> file, but instead fetches the deltas from the knit file (using http +
>> ranges).
>>
>> Which means that the number of fetches are O(deltas) and not
>> O(modified files). It can of course be optimized, but that is the
>> basic idea.
>
> If the knits are packed together for each file, the *number* of fetches
> actually *is* O(modified files). The knits are spread over the modified
> files, so that's one fetch for each of them. And since the chunks are
> ordered by date of addition, you usually want everything from some
> offset till the end of file from each of them.
I agree with you that in the end what you do is "fetch all missing
deltas for knit-file K". But the way you do it is by fetching delta
by delta, based on information from the pulled inventory. So it is a
delta-based, and not file-based, pull. (see fetch.py)
History deltas make this easier since everything is grouped into one
file, and you know exactly what revisions to fetch as soon as you have
collected the ancestry and compared revision histories for the two
branches.
~j
More information about the bazaar
mailing list