for discussion None vs null: vs current:

[Robert Collins]

More grist for the HACKING file.

What do we mean by null: vs None with revision ID's?

NULL in database terms means [roughly] unknown.

That is NULL != NULL, and any operation with NULL, other than 'is NULL'
results in NULL. Selecting records with any formula will not return
records with NULL there - its not less than or equal or greater than any
other value.

We have in bzrlib EmptyTree, and repository.revision_tree() returns
EmptyTree() for revision_id None, but not for revision_id NULL_REVISION.

Yet, in some places we use NULL_REVISION as the implicit common ancestor
for all revisions.


So, I'd like to suggest that we 'start fresh' on this, and do an audit
in the 0.9->1.0 timeframe to clean this up. It will make it easier to
make it all consistent I think.


I propose the following definitions:
'empty:' which will be equivalent to None in python, and refers to the
EmptyTree. So the basis tree for a working tree with no commits has
revision id None, and has the value EmptyTree(). This is the revision_id
returned by 'last_revision()' in a new branch, and is the first revision
in the get_ancestry() list IF the entire ancestry is known. Inside
python we will always generate None for apis which return this, but we
will output it as 'empty:' when serialising - for example in log output,
and we will accept 'empty:' as well as None in all the python apis.


'null:' which will mean an unknown revision. This is the placeholder
revision put into get_ancestry and other apis to represent data we
cannot access - i.e. due to ghosting. 'null:' is defined as never being
equal to anything. So we'll have a magic object that looks like a string
but overloads == to return False. We may want to tweak it further to
make dict lookups fail for it... This will help generate the correct
behaviour for graph traversals and the like. null: will be serialised as
'null:' if we have reason to show it - i.e. an external show_ancestry
command. We will never store it in versioned files or bzr data files.


'current:' will mean the revision_id of a workingtree. current:, like
null: is a magic revision. For this revision, 'current:' != 'current:' -
this is to prevent tree compare shortcircuits and the like, without
needing special casing. We want a different value to null: to allow
'tree.revision_id is CURRENT_REVISION' style clauses to work.


I think thats about it - do an audit, and make all uses match those
three.

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