InterRepo versus StreamSource

Robert Collins robertc at
Tue Jun 2 00:34:55 BST 2009

On Mon, 2009-06-01 at 12:55 -0500, John Arbash Meinel wrote:
> Hash: SHA1
> Overall, I like the way the new StreamSource and StreamSink code works.
> I'm working on an optimized StreamSource for KnitPack => KnitPack that
> doesn't have to deal with format conversions, etc. In doing so, I would
> remove the InterPackRepo optimizer.
> Which revealed something to me. Namely, now that we allow a different
> mechanism for determining inter-object fetching, shouldn't we really
> have that as part of 'interrepository_implementations' (or more
> appropriately per_interrepository) ?
> I've also been finding *lots* of failures with various formats +
> SmartServer, which says that we are missing some real test coverage
> anyway. (Namely, I don't think we have any tests that ensure that every
> format works for basic operations with a source/target of a
> RemoteRepository, since every time I add a tests like that, I find
> failures.)
> Anyway, for now, all of my special cased StreamSource work on exactly
> self._format == to_format, so testing them via 'per_repository' works
> just fine. However, it did seem like those tests should exist in the
> 'interrepository' style tests....

So there are two good answers here I think. One is that we should be
writing to an interface and testing the interface is robust enough. So
failures indicate failing to define the interface well enough via tests.
The other answer is that we should test this code path in a similar
manner to InterRepository and supply some set of combinations to execute

I think either is fine but both is overkill.

-------------- 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 : 

More information about the bazaar mailing list