[MERGE] Fix calculation of search recipe in _get_parent_map_rpc when null: has been seen and is cached as missing

[John Arbash Meinel]

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

Andrew Bennetts wrote:

...

> 
> It's a bit weird to me that NULL_REVISION can considered part of the
> calculated included keys of SearchResult while also being missing.  Present
> revisions obviously can be included but aren't missing, and ghosts will not
> be included and they are missing.  So NULL_REVISION is sort of half-way
> between being ghost and being present, which seems bug-prone to me.  Anyway,
> we can't change how old servers react to NULL_REVISION in a graph, so we
> have to change the client to match.
> 
> -Andrew.

The fundamental problem is that NULL_REVISION itself is a special case.
We don't record it in our indexes, so we have to artificially generate
it. Many apis are unclear whether "foo => ()" or "foo =>
(NULL_REVISION,)" etc. There is a usage which has the former mean 'this
is a ghost', and the latter mean 'this is the first revision', and often
those then turn around and give "NULL_REVISION => ()" which would mean
that NULL_REVISION is actually a ghost, or something along those lines.

Personally, I think we need to re-think our handling of NULL_REVISION.
One of the big problems is that index results have to check *every*
entry to see if we really need to inject NULL_REVISION here, and then
further up the stack we then check to see if we might need to *prune*
NULL_REVISION.

(There are also questions about the parents of the first (file_id,
revision_id) is it NULL_REVISION, [NULL_REVISION] or [(NULL_REVISION,)]
or [(file_id, NULL_REVISION)]

(I think we've settled on either the second or third form...)

Anyway, my personal preference is to not send bytes on the wire when we
know the answer, but you've done the work...

BB:approve

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknSygAACgkQJdeBCYSNAAOIGACdGtLK/1FI6LnV99KY6sjqVNsY
gz8AoImY9RfdxChTnEAoLsQraKkBpm0F
=VNto
-----END PGP SIGNATURE-----