Jelmer Vernooij wrote:
> On Fri, 2009-12-11 at 14:59 +0000, John A Meinel wrote:
>> Jelmer Vernooij wrote:
>>> Public bug reported:
>>>
>>> affects bzr
>>> status confirmed
>>> importance low
>>>
>>> Not all repository implementations provide VersionedFiles. It would be
>>> nice if get_known_graph_ancestry() was exposed as part of the Repository
>>> API so that it can be used for these repository formats.
>
>> You *can* always do:
>>
>> from bzrlib import graph as _mod_graph
>>
>> kg = _mod_graph.KnownGraph(dict(repo.get_graph().iter_ancestry([??])))
>>
>> (You may need to filter out ghosts, which will be repopulated in kg, I'm
>> not positive.)
>>
>> It is, essentially, how I would implement
>> Repo.get_known_graph_ancestry().
> Thanks - it'd be nice if callers don't have to worry about this, and
> implementations may be able to do this faster (bzr-svn in particular
> should be able to do this).
>
> Cheers,
>
> Jelmer
>
Sure, I can see it as an abstract top-level thing. It also would be
faster in bzr repositories to go down to the index.find_ancestry()
functions, and use that to grab a parent map (with keys) and then
translate that back into plain revision_ids, and put that it a KnownGraph.
It sort of depends on how you envision using this functionality.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jelmer Vernooij wrote: graph_ancestry( ) was exposed as part of the Repository KnownGraph( dict(repo. get_graph( ).iter_ ancestry( [??]))) known_graph_ ancestry( ).
> On Fri, 2009-12-11 at 14:59 +0000, John A Meinel wrote:
>> Jelmer Vernooij wrote:
>>> Public bug reported:
>>>
>>> affects bzr
>>> status confirmed
>>> importance low
>>>
>>> Not all repository implementations provide VersionedFiles. It would be
>>> nice if get_known_
>>> API so that it can be used for these repository formats.
>
>> You *can* always do:
>>
>> from bzrlib import graph as _mod_graph
>>
>> kg = _mod_graph.
>>
>> (You may need to filter out ghosts, which will be repopulated in kg, I'm
>> not positive.)
>>
>> It is, essentially, how I would implement
>> Repo.get_
> Thanks - it'd be nice if callers don't have to worry about this, and
> implementations may be able to do this faster (bzr-svn in particular
> should be able to do this).
>
> Cheers,
>
> Jelmer
>
Sure, I can see it as an abstract top-level thing. It also would be ancestry( )
faster in bzr repositories to go down to the index.find_
functions, and use that to grab a parent map (with keys) and then
translate that back into plain revision_ids, and put that it a KnownGraph.
It sort of depends on how you envision using this functionality.
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
ibGUACgkQJdeBCY SNAAMk9QCeO62SH KqpvGqJaTfOQdEM WBld WRfA+qulUWQ/ Xp/Pp
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAks
NT4AoMo0gXbLPgB
=omZP
-----END PGP SIGNATURE-----