[MERGE REQUEST] merge work

[Aaron Bentley]

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

Hi Martin,

Please merge up to and including revision 999 from
http://panoramicfeedback.com/opensource/bzr.24

These changes to the merge code

- - Use "branch -r revno" instead of "branch/@revno", and default to the
last-committed revision.

- - Use bzr structures and conventions instead of BaZing ones.

- - Fixe a bug in the inventory regeneration code, by ensuring that
entries are added parent-first.

- - Calls Merge3 directly on file objects instead of writing and then
reading temp files.

- - When a file has identical contents in THIS and OTHER, but does not
exist in BASE, a clean merge is produced, not a conflict.

Reducing the BaZing flavour means we can avoid regenerating inventory.
For large trees, this is noticeably more efficient; The best-case merge
of the Linux source tree is ~ 4 seconds on my machine, vs 16 sec
originally.

Best case requires

1. we do not check whether THIS has any uncommitted changes
2. OTHER and BASE are RevisionTrees, not WorkingTrees
3. there are no text changes
4. there are no moves or renames
5. stat data is hot.

We do not check for uncommitted changes, because we are benchmarking the
merge primitive, not the merge command.  Total time roughly doubles if
we check THIS for uncommitted changes.

If OTHER is a WorkingTree, total time roughly doubles, but this is
mainly CPU time, not system time (which is still a fraction of a
second).  This suggests that the hashcache could be further optimized.

If there are text changes, there is the additional cost of doing Merge3.
  I seem to get 5sec times with text changes

If there are moves or renames, we must regenerate the inventory, which
costs 3 seconds here.  This is because the inventory has the same
invariants as POSIX filesystems: two entries can't have the same
filename, files cannot have non-existent parents.  It would be nice to
be able to relax these requirements temporarily, but I understand why
this is difficult.

Instead of regenerating the inventory, we could do something similar to
the way renames are handled in the filesystem.  This strikes me as too
complicated, and moves/renames are fairly rare.

With these changes, the spider-goat appearance is much reduced.
MergeTree still exists as a convenient place to associate temporary
directories to RevisionTrees, (e.g. for ApplyDiff3), but its interface
is now pretty compatible with tree.Tree.

The UI no longer supports merging working trees.  Let's see whether
anyone actually wants that, before we look at reintroducing it.  One
approach would be to introduce 'uncommitted' as a '-r' keyword, another
would be allowing --tree instead of --revision.

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

iD8DBQFDAMLp0F+nu1YWqI0RAl1RAJ9QxJ1qYJVEEH5KSnU9NC0FxIocvACfc94G
YYDDqK8NsMoWX50NsVFSNu4=
=PvkQ
-----END PGP SIGNATURE-----