[MERGE] doc update

Aaron Bentley aaron.bentley at utoronto.ca
Fri Jul 13 21:19:24 BST 2007


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

Jelmer Vernooij wrote:
> +There are 5 different slightly different code paths in which bzr update 
> +can be used:
> +
> +* local only (no-op)
> +* lightweight checkout
> +* heavy checkout
> +* heavy checkout w/ local commits
> +* bzr update could work on "bound branch" w/no wt

I think you're oversimplifying.  Update can be used when both the tip
and local branch are out of date.  This causes two merges to happen.

> +no local changes, only new revcs

^^^ "new revisions"?

> +2) apply delta from base to new rev O(Changes)
> +applying diffs to files is approx O(size-of-changed-files)

^^^ There aren't diffs-- this is a merge operation.  The sequence
matching used for merge scales with the square of the number of lines.

> +
> +3) update meta-info about modified files O(Changes) -> O(tree)

^^^ What does this mean?  That the maximum value of O(changes) is O(tree)?

> +done as we apply the changes to the wt 
> +
> +2/3 could be concurrent

^^^ Yes, but this seems less performant than updating all meta-info at once.

These fragmentary comments are really hard to decipher:

> +could build new files in new dirs "in place" rather than at toplevel

^^^ Implemented, if I understand correctly.

> +defecting name conflicts should be O(siblings)

^^^ "detecting", I think.  It is, but it still is expensive, because a
significant fraction of the files in the tree will be siblings of added
files.  This goes back to my arguments against splitting inventories by
directory.

Alternatively, we ought to be able to detect conflicts with existing
files via stat, and detect conflicts with new files by examining the
pending transform.  This would scale with O(changes) instead of O(tree/x)

> +"bzr revert -rOTHER foo"

??

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

iD8DBQFGl95M0F+nu1YWqI0RAlSaAJ9LO0ugxWE942rMQFr9wj+oU5XN6gCcCmv3
LV90pQ+8jZmu9ITvdGekxhU=
=xlky
-----END PGP SIGNATURE-----



More information about the bazaar mailing list