[RFC] remove last-revision and pending-merge separation within the core code.

[Robert Collins]

I've finished analysing merge/pull/update/commit's use of
revision-trees.

We do a lot of double handling, and it will be easiest IMO to remove
this by having the parents of workingtree a single list, rather than a
nullable last-revision and a list.

For instance, merge builds a revision tree during merge. We then build a
new revision tree from the repository during commit to calculate per
file merge history. Commit then makes a new revision tree from the
repository of the inventory it just committed, which is passed to the
tree as the last revision. Thats two unnecessary trips to the repository
- which costs.

I'll write up a spec about how I think the cleanest API can look like -
but I'd like to get broad agreement on the basic change which is:

 * remove set_last_revision
 * remove add_pending_merge
 * probably remove pending_merges() and last_revision()

And replace them with apis that just work on manipulating a parents
list.

Semantic calls on that will take care of removing duplicate parents,
removing parents which are in the ancestry of another etc.

This will change one key thing - it will no longer be possible to have a
last-revision of None and a pending merge - the first parent added will
become the last-revision.

This means that 'init' && 'merge other' will effectively degrade to
'init && pull other'. We could prohibit 'merge into a tree with no
history' to avoid confusion in this case.

Your thoughts?

Rob 




-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060811/f14c53c2/attachment.pgp