[MERGE] handle null revision properly for LCA

John Arbash Meinel john at arbash-meinel.com
Tue Jun 19 22:16:19 BST 2007


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

Robert Collins wrote:
> 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
> 

bzrlib.repository.get_revision_graph(None)

Are you asking for the whole graph, or the graph of the null revision?

We have "solved" it in the past by using a

_marker = object()

def get_revision_graph(revision_id=_marker):

I believe we have this explicit problem with:

bzr branch branch_with_no_revs_in_shared_repo target_not_in_repo

Which copies the entire repository into 'target_not_in_repo', rather than
recognizing that you don't want to copy anything (Vincent found this, there is
a bug).

It isn't the only place. But in general passing "None" is done because you
weren't given anything (so use the last/first/all/none depending on context),
rather than sometimes you have a branch with no revisions so you should be
passing 'null:'. Or you are recursing up through history and you run into
'null:' for some reason. (Arguably [] is better for the parents list).

A hypothetical reason is apis like "Branch.last_revision()" are you returning
None because you don't know, or because you actually meant 'null:' (arguably it
isn't confusing for last_revision() but when you pass that off to
get_revision_graph() what used to be unambiguous suddenly is ambiguous)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGeEejJdeBCYSNAAMRAh9YAJ9mWTKmnQdSxyDHtwMcMpIiM1Tc4QCeNOI0
iw45IbCKLS3k6e67fSD/n6o=
=XDx0
-----END PGP SIGNATURE-----



More information about the bazaar mailing list