[MERGE] Deprecate last-revision and pending_merges.

[Martin Pool]

On  5 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > Theres a semantic disconnect between Branch which represents a sequence
> > (well, graph technically) of RevisionTree's, and WorkingTree which
> > represents a single tree.
> > 
> > last-revision is entirely appropriate when you are working with a
> > sequence, but it does not fit WorkingTree well at all - its not
> > something that is defined for RevisionTree or other trees, and there is
> > no sequence or graph that a Tree represents - Tree is the node in the
> > graph.
> 
> The leftmost revision is a favored revision.  It is used as the basis of
> comparison for diff and status, and when there is no leftmost, the null
> revision is used.  This is an exact match for last_revision.
> 
> The commit and info code show that we consider Tree.last_revision to be
> similar to Branch.last_revision, for the purpose of determining whether
> a bound branch is up to date.
> 
> It might be reasonable to rename last_revision to basis_revision, but I
> don't think it makes sense to remove it.

I agree with Aaron.

> In fact, I was actually considering adding a basis_revision method to
> all trees, but for RevisionTrees, it would return
> RevisionTree.get_revision_id().  That would simplify the merge code a
> bit, because we would only need trees and repositories.  Branches
> wouldn't be needed.

That makes sense too.

-- 
Martin