David Allouche wrote:
> The bzr+ssh:// instead of sftp:// transport (supported today by
> Launchpad) should not have this problem: if the connection is
> interrupted, the server-side bzr process can still release the lock.
This may be true eventually, when the bzr+ssh:// protocol has implemented
everything in terms of high-level domain objects. At the moment almost every
operation falls back to file-level requests, which means taking out file-level
locks of exactly the same sort as SFTP.
So using bzr+ssh:// will not avoid stale locks, at least not today.
David Allouche wrote:
> The bzr+ssh:// instead of sftp:// transport (supported today by
> Launchpad) should not have this problem: if the connection is
> interrupted, the server-side bzr process can still release the lock.
This may be true eventually, when the bzr+ssh:// protocol has implemented
everything in terms of high-level domain objects. At the moment almost every
operation falls back to file-level requests, which means taking out file-level
locks of exactly the same sort as SFTP.
So using bzr+ssh:// will not avoid stale locks, at least not today.