Introduction to history deltas

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Hudec wrote:
> On Tue, Dec 06, 2005 at 01:10:13 -0500, Aaron Bentley wrote:
>>That is similar to knits.  I believe knits could be used to represent
>>the diffs for history deltas, if using a weaveish format was desired.
> 
> 
> There is one interesting point in the original suggestion: Instead of
> storing all chunks for a file together, it stores all chunks for a
> revision together.

Right.  So one way of looking at it is as a hunk organization method.
You would either organize hunks by file (like weaves do) or by revision
(history deltas).

> 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.

With bzr.dev, the crossover point is 196 revisions.  Downloading 197
revisions with history deltas would be 197 downloads, but with per-file
knits, it would be 196.  (That is, if you have revno 1276, and you're
updating to the current 1473.)

The other issue is generating full texts.  Bzr hardly ever needs full
trees, because it compares files to the hashcache.  So when doing diff,
merge or commit, it only requires the full texts of the files that have
been modified.  That suggests that it's an advantage to optimize for
single file access, locally.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDlZkf0F+nu1YWqI0RAqheAJ420q31bNXT68e1ek5nE+nFsAZsuACeIwBU
8Q0U/bQuI4J3WzD2Kd/MsQk=
=JIe5
-----END PGP SIGNATURE-----