Introduction to history deltas

Jan Hudec bulb at ucw.cz
Wed Dec 7 07:06:16 GMT 2005


On Wed, Dec 07, 2005 at 07:12:56 +0100, Johan Rydberg wrote:
> 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.

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.

The *size* of the fetch is O(size of the change), which is right. This
is so independently whether the knits are grouped per file or per
revision.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051207/cc1d99df/attachment.pgp 


More information about the bazaar mailing list