Transport w/ extra tests

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>
>>>Aaron Bentley wrote:
>
>
>>>Or we could include an
>>>.errno value, which could be used similarly to IOError.errno.
>>>I suppose I prefer the individual exceptions, because I think it is
>>>easier to catch them, than to trap an error and check the errno.
>
>
> I agree.  Also, if the errno doesn't match, you must re-raise the
> exception, which messes up the traceback.

Do you have a specific list of desirable exceptions?
Obviously NoSuchFile is one. There is also TransportNotPossible (which I
already have) to indicate stuff like you can't write to an
HttpTransport, and you can't stat Http, (Sftp gives a NotImplemented,
because I think it is possible long term).

Anything else? Perhaps a TransportTimeout of some sort. (I know
effbot.org can give a timeout for a download taking to long, but that
may not be the best place to do it)

>
>
>>>Well, they all throw TransportError, but I agree, that type is too opaque.
>
>
> - From what I can tell, the handling isn't consistent.  e.g.
> HttpTransport.get() will throw a BzrError if the file doesn't exist.
>

Only because HttpTransport isn't fully compliant. :) Actually, I need to
setup a readonly test suite. Right now I only have the read-write test
suite written. (and it is a little tricky to test Http, since you would
have to have an http server. Unless we trick HttpTransport into also
supporting file:// type urls.)

The nice thing about rsync is that it can work on the local filesystem,
and for SftpTransport at least *I* almost always have sshd running.

>
>>>You wouldn't have to have the encode/decode. Except, in the Branch
>>>class, there are a lot of locations that require encode/decode, and I
>>>thought it would be easier to do that at the lower level rather than the
>>>higher.
>
>
> By my count, there are only 8 call to get and put, so the transition
> wouldn't hurt much.

Sure.

>
>
>>>Certainly we can rewrite more of Branch to use a different function call
>>>(rather than _transport.get) which wraps the return value
>>>_transport.get()
>
>
> I think it makes more sense to handle encoding issues in Branch.  It
> would be fine with me to enforce 100% UTF-8 control files.  ElementTree
> will auto-decode bytestrings, but will it leave unicode data alone?

Actually, ElementTree automatically decodes/encodes into utf-8. But the
other control files need to be handled specially. (Notice that reading
inventory is done in binary form).

>
> I'm pretty sure we should not use the 'b' flag as a hint about whether
> the file is encoded or not.
>

I generally agree, that is just what used to be done for control files.

> Aaron

If I get some time, I'll look into adding some new exception classes,
and moving the encoding stuff higher up.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050719/d54beccc/attachment.pgp