plugin: sftp transport

John Arbash Meinel john at arbash-meinel.com
Sun Oct 23 00:20:14 BST 2005


Robert Collins wrote:
> On Wed, 2005-10-19 at 21:54 -0500, John A Meinel wrote:
> 
>>Martin Pool wrote:
>>
>>>On 19/10/05, John Arbash Meinel <john at arbash-meinel.com> wrote:
>>>
>>>
>>>>Martin Pool wrote:
>>>>
>>>>
>>>>>If it's OK with you I'm going to make this a builtin transport.
>>>>>People will still need to have paramiko to actually use it.
>>>>
>>>>I'm concerned that you put sftp support into the core without actually
>>>>adding test cases for it. (This shouldn't be very difficult)
>>>
>>>
>>>I know, I normally wouldn't have but Robert twisted my arm.
>>
>>I thought Robert was the one who advocated "test driven programming".
> 
> 
> Absolutely, but our primary focus is developing bzr, not creating a
> bunch of TDD junkies :) - Though I am absolutely keen on doing that too.
> Once code is written though, its no longer test driven design/test
> driven programming. So while Martin and I are both concerned about
> keeping test coverage up, if a constributor / potential contributor has
> written code-first modules, (and most folk do), TDD is already not in
> play there :[. So - pragmatism will come into it a lot too.
> 
> I twisted martins arm for a couple of reasons ...
> I think its better to have 'a' sftp transport in the core, even if its
> not the long term one, because it reduces the number of spurious reworks
> of the same problems - this is the same reason I was pro transport
> coming in even though I had not had time to deeply review the code :
> many issues were requiring something *like* transport.
> Also, I have been dying for sftp for doing up cmd_push :).

I understand your point. I was just surprised because at least in theory
I had made writing tests for any transport a simple inheritance. Though
you may not have been aware of it at the time.

I'm glad sftp was merged. I just didn't like that the way it was done
broke bzr, such that it couldn't even update itself once a fix was made
(without hacking the source).

But all this has been fixed (and even improved upon).

Speaking of getting things merged so as to reduce spurious development,
both Aaron and I would like to see my changeset work merged into the core.
I recently updated it against all of your latest changes (the removal of
text_ids, the open_containing() change, etc).

I believe it still needs a way to handle binary files, symlinks, and the
execute bit.

But having it would allow for "undo" like functionality to save a changeset.

Have you or Martin had any chance to look over it?

Oh, and what was the status of merging in the "uncommit" command. Aaron
just asked to merge it into bzrtools (which he probably has done), but I
know at one time we were thinking it would become a builtin command.

John
=:->

PS> I will also agree that the code could probably be cleaned up.
Originally it was actually written more as a proof of concept of how a
changeset could look.

> 
> Rob
> 

-------------- 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/20051022/8a6d5f5a/attachment.pgp 


More information about the bazaar mailing list