[MERGE] handle null revision properly for LCA

[Robert Collins]

On Tue, 2007-06-19 at 10:57 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> The new Graph methods require that the null revision be expressed as
> 'null:' not None.  Using None has turned out to be a bad idea in our
> APIs, so I propose that all new APIs accept only 'null:'.

Can we examine this a bit more? How/where has None been a problem. I do
remember that we had a confusion with ghosts in the past - 
A:[] (no parents) 
was confused with
B:[] (all parents are ghosts)

these days you get
A:[] (no parents)
B:[ghost, ghost, ghost]

if you use the ghost aware API

I guess fundamentally I don't get the differences between None, an empty
list, and NULL_REVISION within bzrlib.

It just seems more work to say "every revision will always have a non
empty list of parents except the pseudo revision 'NULL_REVISION'" rather
than "Every revision has a list of parents which may be empty".

Specifically having NULL_REVISION as a parent returned in queries means
that some revision ids returned cannot be accessed - theres no 'commit
date' for NULL_REVISION (and there shouldn't be). OTOH we may need a
concept for the current trees revision at some point, which will have
the same defect.

-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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070620/524c07ef/attachment.pgp