Introduction to history deltas

Johan Rydberg jrydberg at gnu.org
Wed Dec 7 06:12:56 GMT 2005


Aaron Bentley <aaron.bentley at utoronto.ca> writes:

>> That would spead up remote transactions, because
>> you'd not have to copy all the files to create their new versions
>> atomically, but instead atomically install one file. For reading, index
>> files are needed in either case.
>
> It's not a clear win.  With history deltas, your latency scales
> per-revision; with file-knits, your latency scales per-file.  So for
> operations like branch, you'd rather have per-file latency, (because you
> usually have more revisions than files) but for operations like pulling
> 3 revisions, you'd rather have per-revision latency.

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.

~j







More information about the bazaar mailing list