What is KnitPackStreamSource _for_

[Robert Collins]

On Thu, 2009-06-18 at 22:19 -0500, John Arbash Meinel wrote:
> 
> StreamSource can't make as much assumptions about the data stream
> because it is more generic.
> 
> 1) It can't assume atomic inserts so it sends texts before
> inventories.
> This requires either buffering the inventories or reading them twice.

For our formats, when fetch_order != 'topological' we have atomic
inserts. We could make that an explicit attribute on the repo format
too.

> 2) Similarly about fetching in topological order for Revisions (it
> does
> a topo_sort that we don't need.)

A topo sort is useful because it means adjacent revisions are adjacent
on disk. So its not -needed- but actually there is a bug open somewhere
about knitpack not ordering on disk properly.

> 3) Because it has to handle all permutations, the code is *much*
> harder
> to write and read, and certainly make perform optimally. Having a
> simple
> "data X to data X" stream is much cleaner (IMO). For example, all of
> the
> code to handle converting between rich roots, or chk formats, or...
>
> I'm not sure how you want this documented. I'll be happy to flesh out
> whatever you would like.

Well, I really want to get to one code path that we can test rigourously
and be sure is complete. So I want to have precisely two sinks and
sources:
 * real
 * remote proxy

Without getting to that point its a _lot_ harder to be confident about
behaviour and robustness over the network.

If we are going to have subclasses, we should make *old* or *less
capable* formats have the subclasses, not the default implementation.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090619/aacf2fe7/attachment.pgp