What is KnitPackStreamSource _for_
robert.collins at canonical.com
Fri Jun 19 04:25:24 BST 2009
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
> 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
> 2) Similarly about fetching in topological order for Revisions (it
> 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*
> to write and read, and certainly make perform optimally. Having a
> "data X to data X" stream is much cleaner (IMO). For example, all of
> 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
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090619/aacf2fe7/attachment.pgp
More information about the bazaar