Introduction to history deltas

[Aaron Bentley]

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

Matt Lavin wrote:
| Aaron Bentley wrote:
|
|> 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).
|>
|
| Hopefully this will not be a completely off-topic comment, but if a goal
| of bzr is to ever support a partial checkout of a tree then it seems
| like it would be better to have the data organized by file, not
| revision.  Maybe not,  but I thought I'd throw it out there anyway.

It seems like a partial checkout that lost the data about un-checked-out
files would probably cause problems if you ever wanted to merge with a
fully-checked-out version.

My idea for partial checkouts was that you would store all the data for
the full tree in the .bzr directory, but also specify a directory to use
as root.  Any files that were not descendants of the new root would be
considered 'unchanged' by commit, status, etc.

I'm not sure what would happen if a partial tree merged a full tree,
especially if there were conflicts.

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

iD8DBQFDmJyH0F+nu1YWqI0RAtJVAKCINjNcAT8q1lIHLbFZkDQEmPChdACfTM9k
e/CK1oXp3XiDXXr57zjaYFo=
=LUXn
-----END PGP SIGNATURE-----