Transport w/ extra tests

John A Meinel john at
Mon Jul 18 21:05:11 BST 2005

On my branch of bzr which uses a Transport hierarchy to support multiple
protocols, I've added a test suite for people attempting to implement a
RW Transport. I've put the LocalTransport class through it.

Being inspired by Robey's SftpBranch work, I went ahead and created an
SftpTransport plugin, available here:

I adapted my RsyncTransport class, so I went ahead and did it by
spawning the actual sftp program, rather than using paramiko. I think a
paramiko one could do a lot better, since it doesn't have to
re-established a connection for all the different operations. I wrote it
in such a way that spawning sftp can be used as a fallback.

My SftpTransport does pass the test suite, and so does my old
RsyncTransport. The problem is that the test suite also makes sure that
exceptions are thrown (like creating a directory whose parent doesn't
exist). And that is a little bit more expensive with Rsync (you have to
do a pull to see if anything exists). I'll probably implement it anyway,
just to have the RsyncTransport be 'correct'.

Mostly, I just wanted people to know that I've updated my branch. If
Robey gets inspired, it would be nice to have a paramiko style
SftpTransport object. (I only didn't implement it, because I implemented
this while disconnected, and didn't have paramiko installed, but could
sftp to my local machine).

One other *huge* benefit for paramiko is that people who don't have keys
setup, and actually have to type their passwords, will probably find
regular SftpTransport unusable. Because for each (possibly multiple)
query, it spawns a new sftp subprocess, with all of the connection overhead.
But I did mean it as a test of Transports, and as a potential fallback
(so that people don't have to install paramiko).

Just as a brief reminder, my Transport work allows read/write access to
control directories. But not Working trees. Partially because we haven't
decided if we want to support remote working trees.

And in testing, I found that
bzr branch -r 100 rsync://
takes only 30s to complete, while
bzr branch -r 100
takes 1m51s
The non-Transport version of bzr also takes 1m50s to download over http.
Neither one of these is pipelined, but I believe pipelining my
HttpTransport should be fairly easy, since I already have the
"get_multi" function call. (Part of the improvements in my Transport
branch is to change most loops over files into a single large request,
and then looping)

Anyway, hopefully people can experiment with these (both the Transport
branch, and the Sftp and Rsync versions).
If you find bugs, let me know. (Or if you can even just include more
tests in the various test suites.)


PS> It would be nice if we had a way to have "bzr selftest" only run
certain tests. So that when you are doing some development, you can only
run the tests you care about, until you get them working, and then go
back and run everything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : 

More information about the bazaar mailing list