[MERGE] Repository.missing_revision_ids -> search_missing_revision_ids

John Arbash Meinel john at arbash-meinel.com
Thu Jan 17 19:52:33 GMT 2008


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

Robert Collins wrote:
> This replaces the missing_revision_ids API with
> search_missing_revision_ids.
> 
> There are two key differences:
>  - the new api returns a SearchResult
>  - SearchResults do not offer topological ordering results at the moment
> 
> This is a stepping stone to reducing initial-branch network traffic.
> 
> -Rob
> 


>      @needs_read_lock
> +    def search_missing_revision_ids(self, other, revision_id=None, find_ghosts=True):
> +        """Return the revision ids that other has that this does not.
> +        
> +        These are returned in topological order.
> +
> +        revision_id: only return revision ids included by revision_id.
> +        """

^- You just said that they are not in topological order, so the
docstring should be updated to reflect that.


Is it possible to implement a compatibility
"search_missing_revision_ids" which is implemented in terms of
"missing_revision_ids"? I'm thinking for plugins like bzr-git/bzr-svn
which may not have implemented the new API yet, it is nice to have them
still work.

Unless it is expected that the generic "search_missing_revision_ids"
would work for all other implementations. It looks like you might be
doing it as a series of set operations, which seems like it would work
for all repositories.


> +        for parents in repository.get_graph().get_parent_map(
> +            result_set).itervalues():
> +            result_parents.update(parents)

^- This would be one of those cases where we wouldn't want
"get_parent_map()" to return more items than requested. Obviously if we
changed the api, this could be rewritten to filter at this point.


> === modified file 'bzrlib/symbol_versioning.py'
> --- bzrlib/symbol_versioning.py	2007-12-18 15:22:47 +0000
> +++ bzrlib/symbol_versioning.py	2008-01-17 03:14:20 +0000
> @@ -43,6 +43,7 @@
>             'zero_ninetythree',
>             'one_zero',
>             'one_one',
> +           'one_two',
>             ]


^- I thought adding the symbol_versioning strings was supposed to be
part of the release process. (After you've released 1.1rc1 you are
supposed to update NEWS and create a deprecation string.) If it isn't
formally listed, it seems like something we should add.

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

iD8DBQFHj7IBJdeBCYSNAAMRAu/sAJ9rWLrtiqbt+WVG4blx/jRuqfZAIwCgstsK
Cy1cgRkeUxOwlxZO0OU/qJs=
=V4H3
-----END PGP SIGNATURE-----



More information about the bazaar mailing list