[MERGE] Deprecate last-revision and pending_merges.

[Aaron Bentley]

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

Robert Collins wrote:
> On Wed, 2006-09-06 at 14:47 +1000, Martin Pool wrote:
>> On  5 Sep 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 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.

In the current code, None is an identifier that produces the null
revision's tree.  I agree that None is not ideal for the purpose.  See
my recent email to Robey, for example.  But calling it inaccurate is
wrong.

My feeling is that if we don't like what last_revision returns, we
should change what last_revision returns.

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

I agree, but this is beside the point.  The use of None as an identifier
for the null revision's tree is spread throughout the code, and merely
deleting WorkingTree.last_revision doesn't fix anything.  By that
argument, we should delete Branch.last_revision and
Repository.revision_tree, too.

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

I proposed that the basis for all RevisionTrees is their own revision
id, not the revision id of one of their parents.

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

I think you've got your order of operations wrong.  Let's stop using
None to represent the null revision's tree first.  Then let's look at
getting rid of last_revision, if it still makes sense.  There's no
reason to make the perfect the enemy of the adequate.

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

iD8DBQFE/0280F+nu1YWqI0RAq9OAJ9WayJ9SoDVotemU3Px1Zt0KS5DKQCfTCE1
7CX0ODfpKjEfjvFEFsHI+k8=
=jYgk
-----END PGP SIGNATURE-----