[RFC][PATCH]

[John A Meinel]

Robert Collins wrote:
> Hi, http://people.ubuntu.com/~robertc/baz2.0/test-providers is ready for
> a review.
> 
> I think its ready for merge with one caveat, which I need some input on:
> the new mode tests.

Well, other than the fact that fancy_rename was borked causing *many* of
the tests to fail (which was fixed in the same manner, just catch
ENOTDIR and ENOENT).
It seems reasonable.

I would like to see it easier to add new transports, since right now all
of the transports have to be instantiated directly by the TransportAdapter.

also, you mix where the test code is, and where real code is. I thought
we wanted to keep them apart.

There were a couple of new exceptions that weren't in errors.py, though
it didn't seem bad.

> 
> 
> The problem is discriminating between transports that can set modes, and
> transports that cant set modes. 
> 
> For instance, HTTP can never do modes - the protocol does not 'get' it.
> SFTP can - and we could make stub_server talk to a transport instance
> with MemoryTransport backing it, to get a sftp server with mode support
> on windows.
> MemoryTransport can do modes, but does not write to the fs.

Well, you would have to have the local transport server also use a
memory backed stat on windows if you want mode support across the board.

> 
> So right now Johns new transport tests are inactive, because they are
> all in the defunct test_transport TransportTestsMixIn class. 
> 
> I can see several routes out:
> 
> a) test mode setting as part of the Transport interface: check the modes
> are set via stat(), and skip those tests on win32 and for read only
> transports.
> b) have two implementation tests for transport - one for the primary
> interface, and one for mode aware transports 
> c) test that the mode is set on the backend correctly on a per transport
> basis (basically c, but along the lines of the old transport tests.)
> 
> My preference is a), but I wanted input first..
> 
> and separately to that, I'd just -love- a +1 for the rest of the branch.
> 
> Rob
> 

I would go for a) as well. I'm +0.5 right now, since a 3k diff is a lot
to go through.

Can you reexplain why you prefer to Adapt rather than Mixin?

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/20060104/1bd9137b/attachment.pgp