plugin: sftp transport

[John Arbash Meinel]

Robert Collins wrote:
> On Wed, 2005-10-19 at 09:27 +0200, Jan Hudec wrote:
> ...
> 
>>The locks must not be transport specific. They must work for all
>>protocols. Ie. reader over HTTP must notice that someone is writing over
>>SFTP. And HTTP does not support fcntl locks, so even if new sftp does,
>>they are of little use. When webdav and plain ftp are added, they also
>>won't handle those.
>>
>>In addition, I think full transaction semantics is necessary. Because
>>when a connection breaks, any other client must be able to break the
>>lock and continue. And if the connection was not actually broken, only
>>too slow, the first client must just say "Transaction failed, try again"
>>and upon restart properly do whatever it was up to.
>>
>>Which boils down to some kind of renaming stuff like tla/baz do.
> 
> 
> So, read lock can be considered advisory. In fact, once we have all our
> code transaction-integrated (including batching commits of atomic files
> with write lock removal), I plan to remove the read locking from
> branch : it will still have a lock_read call, but it will simply
> activate a read transaction, which gives caching to data objects.
> 
> With respect to the requirements for write locks... it seems to me that
> if you are publishing a multi user repository with write access, you
> should be choosing just one write method anyway. Theres a lot of
> complexity bounding up in the directory renaming lock logic of tla/baz -
> do we really need it ?

Well, I believe with the sftp v6 protocol you can obtain an exclusive
lock on a file, which is the same as a local exclusive lock. (When the
session goes away the OS releases the lock, etc).

I've heard that the only locking for v3 (the common implementation) is
to create a new file with the exclusive flag.

One thing I think we need to do quickly for the sftp transport is to
change the put function so that it uploads to a temp file, and then
renames into place, so that we can get atomic changes. Otherwise pushing
to an sftp branch would be a really good way to corrupt your remote
weaves by having a timeout.

I was also wondering about Tom's later proposal (not arch, maybe revc)
where he implements a transactional message queue. I'm not suggesting
that we put all of the data into those directories, but we could perhaps
put either the revision-history file into something like that, or even
just have a transactional directory. So that you can query to see if
there is a lock right now, or to place one, and you can commit, etc,
bound to some transaction that is currently pending.

I believe that in general bzr achieves transaction independence by
having all activities associated with a unique identifier, and then that
identifier being present is what truly defines the transactions. At
present, that is "revision-history".

So as long as all files are either atomically updated, or append updated
(preferably the later). And any updates are bound to some sort of key,
the only thing that needs to truly be in a transaction is that key.
(Except nobody else can add new keys to the system if one is being added).

Long story short, I think we can get a form of write locks for multiple
protocols, without having to give up everything that Arch did.

John
=:->

> 
> 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/b0ae85eb/attachment.pgp