[MERGE] Deprecate last-revision and pending_merges.

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Tue, 2006-09-05 at 19:42 -0400, Aaron Bentley wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Robert Collins wrote:
>>> This deprecates last_revision and pending_merges from the WorkingTree
>>> interface in favour of get_parent_ids.
>> Don't we want to keep last_revision as a convenience method?  I notice
>> several places where the elimination of last_revision has made the code
>> longer.  last_revision makes it easier to write correct code, rather
>> than calling "get_parent_ids()[0]" without a try block.
> 
> I thought about that for a bit, and I think that no, we shouldn't.
> 
> 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.

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.

> I think that the code that is harder is temporary -  if we change
> WorkingTree to have an explicit first parent of 'empty:' when first
> created, and thus to never have no parents, then the code that is harder
> at the moment will become safe again, without the overlaid behaviour
> between sequence-and-snapshot that last-revision has.

I agree that endpoint sounds nice.  Does retaining last_revision hamper
you from reaching it?  If not, can we keep it 'till then at least?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE/iUO0F+nu1YWqI0RApK0AJ9ydJ/0kl+cd5+d8RIPpO3tQovE+wCfc4ku
KlOJAvsF95478MTXZ38vUZ4=
=Z5lo
-----END PGP SIGNATURE-----