Serializer_v5._pack_revision and _unpack_revision to become public?

[John A Meinel]

David Allouche wrote:
> On Sun, 2006-02-12 at 12:13 -0600, John A Meinel wrote:
>>> On a higher level, the requirement is "get the complete ancestry of a
>>> revision, with placeholders for ghost revisions".
>> Is there a reason you can't get the weave and go through the ancestry
>> map there. And then lazily load the revisions?
> 
> Mhhh... I'm not sure what you mean. If you mean extracting the revision
> graph from some weave (which one, the inventory?), I guess that would be
> feasible. At least that would be useful for automatic cache
> invalidation. But I'm not sure that could allow identifying ghost
> revisions. Does it?
> Also, the revisions data (things like commiter, branch nick) are needed
> to choose the color of arcs.
> 
> I guess it would be possible to load revisions incrementally, but that
> would require a much more complex logic, just to work around bzrlib
> slowness.
> 
> Is there a reason bzrlib cannot be faster a getting revisions?

Other than the fact that not everything can be super fast?

If you can find the specific reasons why we are slow please do so. I
have the feeling it is just the time to parse XML. And I know Martin has
some ideas of switching to a different format.
We might also be able to write some bits in C/C++. But I think we want
to get the algorithms fast first. (Using knits will be a lot faster than
using optimized weaves, for example).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060215/2af6039e/attachment.pgp