[RFC] Workingtree.set_parent_trees()

[Robert Collins]

On Wed, 2006-08-09 at 09:04 -0500, John Arbash Meinel wrote:
> 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:'.

Ghost trees - we could have a special ghost tree with some special node
at the root, but it seemed cleaner to me to have the tree explicitly not
available in the api.

> > 
> > 
> > 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[0][1].inventory rather than unpacking it anew from the
> > repository.
> > 
> > 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.
> > 
> > Cheers,
> > Rob
> 
> 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).

Try this in 0.9:
init A
commit A
init B
cd B
merge ../A
commit
uncommit
your last revision is now that of A.

Our history data format does not discriminate between parent 0 and 1 -
nor does anything else in the code *outside of workingtree*. I like the
consistency this brings - its part of why the pull/merge split works so
naturally. 

> 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.

I have been testing and tweaking callers - I now have three calls:
set_parent_trees()
set_parent_ids() # does the tree lookup for the caller
add_parent_tree()
add_parent_id() # does the tree lookup for the caller 

In a tree format where the parents are not cached, the implementations
of the _ids forms would naturally just set data rather than doing
lookups.

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/20060810/e27b263b/attachment-0001.pgp