[MERGE] Deprecate last-revision and pending_merges.

[Robert Collins]

On Wed, 2006-09-06 at 14:47 +1000, Martin Pool wrote:
> On  5 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > Robert Collins wrote:
> > > basis_revision might be nice, but I'd want it to throw if there is no
> > > left most parent - to avoid this inconsistency where we consider there
> > > to be an implicit tree sometimes and not others. (Thats another thing I
> > > dislike about last_revision).
> 
> So it would throw if you asked it for the basis of the first revision of
> a branch, or of a working tree in a newly-created branch?  Why?

> > The way I see it, last_revision is consistent, but when the
> > last_revision is the null revision, different bits of the code behave in
> > different ways.  If it returned 'empty:' or 'null:' instead, you'd still
> > get that.
> 
> Again, I agree with that.


Right now theres currently no value returned by last_revision that
represents the parent accurately for trees with an implicit left most
parent - we return None instead. We've had and still have a raft of bugs
that turn up again and again because the last_revision() of a new
WorkingTree does not behave the same as the the last_revision of all
other trees. Specifically, returning None for the last revision makes
functions that accept an optional parameter (revision_id=None) misbehave
when they are naively chained together.

We have a plan to introduce specific revision identifiers to represent
'the implicit base tree' - at which point this first objection goes
away.

Secondly, unless we make the statement 'all trees will always have one
or more parents', there will be a black hole bootstrap point. I.e. 
EmptyTree().get_parent_ids() -> []

So if the basis for a new WorkingTree is going to be 'empty:', what is
the basis for an EmptyTree ? if thats 'empty:' then we have infinite
loop problems. If its None, we have the current unpleasantness. If its
'null:', what is the left most parent of a null: tree ? null: ? More
infinite recursion.

Basically we need a stop point, and its easier to ensure that accidents
do not happen by having it raise an exception - StopIteration by analogy
- than by giving it a special boundary value that *every caller* needs
to check for.

I feel quite strongly that the following combination is OK:
 * the implicit root tree has no parents.
 * last_revision/basis_revision/basis_tree on the implicit root throws
 * a new WorkingTree has a basis which is the implicit root

And that bringing in apis which do not step us closer to that is
unhealthy and will simply be churn.

Thats why I want to get rid of last_revision - it *is* harmful as
currently defined. And its why I want basis_revision to be defined in a
beneficial way.

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/20060907/5d6fd7d4/attachment.pgp