John Arbash Meinel
john at arbash-meinel.com
Wed Aug 9 15:04:00 BST 2006
Robert Collins wrote:
> I have a new api I plan to introduce:
> WorkingTree.set_parent_trees(self, parents_list):
> """Set the parents of the working tree.
> :param parents_list: A list of (revision_id, tree) tuples.
> If tree is None, then that element is treated as an unreachable
> parent tree - i.e. a ghost.
Out of curiosity do you need the 'revision_id' parameter? It seems that
trees should know their revision id. (Inventories generally do, if it
hasn't been exposed at the tree level yet).
WorkingTree could return 'current:' as we proposed. And "EmptyTree"
could return 'null:'.
> This supplants both WT.set_last_revision and WT.set_pending_merges. Its
> designed to give the tree object the maximum data it needs in one hit to
> avoid needless handshaking that currently happens. (for instance,
> caching the basis revision can be done by taking
> parents_list.inventory rather than unpacking it anew from the
> I think this is a win for all tree types - but do we still want
> set_last_revision and set_pending_merges? In some ways its nice to have
> these separate semantically clear apis, but in another respect its kind
> of misleading - the specialness of the first parent vs the other parents
> is rather less in our underlying storage than the api suggests. (See for
> instance my abuse of the api to do correct imports from baz).
> I'd like to deprecate set_last_revision and set_pending_merges in favour
> of set_parent_trees for 0.10.
It seems a little funny that the merge code would potentially change the
last_revision. (Because it adds a new pending merge).
Also, when merging, you don't change the last_revision, so you don't
have to change the basis inventory. I don't even know that the merge
code had to read it to do the merge. (It needs the last_revision, so it
can find a common ancestor, but after that it needs the working
inventory, not the basis inventory).
So I really like the idea of passing WorkingTree everything it needs
that you already have. But I don't know that you always have everything
it needs. And in fact, you may not have things that it doesn't
*actually* need, but that the API requires.
At this point, I'm +0.5 on your proposal. It seems like once it happens,
we have to shoe-horn requests, rather than a real simplification to the API.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060809/d70b9e01/attachment.pgp
More information about the bazaar