[rfc] [patch] sftp unit tests without ssh

[John Arbash Meinel]

Robey Pointer wrote:
> 
> On 23 Jan 2006, at 8:17, John Arbash Meinel wrote:
> 
>> Robey Pointer wrote:
>>
>>> I think I figured out how to hook up a single "full" sftp test (using
>>> ssh), so my bzr.dev.sftp branch now includes that extra test, plus a
>>> warn -> warning typo fix.  To avoid spamming the list with huge
>>> patches, I'm attaching only a patch against the previous patch.
>>>
>>> robey
>>>
>>
>> The patch looks good.
>>
>> The only conflict against your branch is the 'if getattr()' line.
>> Because I used:
>> if getattr(attr, 'st_mode', None):
>>   foo
>>
>> and you used:
>> if getattr(attr, 'st_mode', None) is not None:
>>   foo
>>
>> The problem with yours is that even though paramiko only uses 0 for a
>> short time, *I* still have that version, and I assume other people  might
>> too. So we want to check for both None and 0, which both conveniently
>> evaluate to False.
> 
> 
> That's fine with me... though just to eliminate variables, I'd prefer 
> if everyone just stuck with paramiko 1.5.2 for now.  Which pains me  to
> say cuz I love having instant feedback :)  ... but fluctuations in  the
> daily state of the paramiko tree will just end up confusing &  masking
> real bugs, IMHO.
> 

Well, somehow it needs to be tested. But really, I can also say that if
you use the development version, then be prepared to upgrade the dev
version when bugs are found.
So I don't think we have to worry about maintaining bzr compatibility
with every revision in paramiko. But you didn't have a fix yet.
That and I'm having trouble pulling the tree now, because it fails to
install revisions.

> 
>> I went ahead and test merged your bzr.dev.sftp branch into
>> jam-integration. I'm not sure what happened, but the first time I ran
>> it, it just hung after all the tests had run. I'm guessing a server
>> thread wasn't being shut down properly.
>> The second time I ran it, I didn't have any problems.
> 
> 
> I suspect something must've gotten scrambled when merging, but I  don't
> think you checked in your merge (bzr.jam doesn't have it) so I  can't
> verify it.  Actually a pull of your tree reveals uncommitted  changes --
> is that even possible?  Weird.  I'm gonna blow away that  branch and
> pull a fresh copy.

I didn't commit the changes, I just looked to see what would happen if I
did.
If you do a checkout and have uncommitted changes, that usually means
that you have uncommitted changes in your local tree before the pull.
Pull shouldn't ever create uncommitted changes.

> 
> [a few hours later...]
> 
> Well, good news and bad news.  The good news is that I get the same 
> speedup with a bzr.dev.sftp + bzr.jam monster merge.  The bad news is 
> that it has 19 failures and 50 errors.  They're all in non-sftp- related
> code.  Also I had 3 conflicts during the merge (again, none  related to
> my changes).  I think if you merge up with bzr.dev first  you might have
> better luck, but it looks like the 2 trees have  diverged too much right
> now.
> 
> robey

I just merged bzr.dev. bzr.dev has merged all of me through Robert's
integration branch. So I'm not sure why you have changes showing up.

Something seems odd with your setup, as I don't seem to have the same
issues on my end.

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