plugin: sftp transport

[Robert Collins]

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 ?

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051023/d752e985/attachment.pgp