sftp locks can get stuck

[Robey Pointer]

On 20 Dec 2005, at 17:56, John Arbash Meinel wrote:

> Robey Pointer wrote:
>>
>> There are some heuristics we could do to cut out some cases.  For
>> example, we could write the lock-owner's email address into the lock
>> file, so that we could automatically recover from a stale lock  
>> that  was
>> just left behind by one of your own previous sessions.  (It also   
>> helps
>> you figure out who to ping if you're on a shared project and  feeling
>> conscientious.)
>
> True. But as long as you don't forget you can push from more than one
> machine, though you are likely to serialize your access. (This may
> become more likely once we get bound branches, since there will be  
> more
> remote access going on).

Yeah, so we should be storing both the email & the IP...  or is that  
getting into the area of diminishing returns? :)


>
>>
>> If all writes are transactional (are they?), then we could add a lock
>> check phase right before the final commit: make sure that we  
>> still  own
>> the lock.  Assuming the final commit is short, that would let us   
>> use a
>> timeout of something much smaller, like 15 minutes.  That would   
>> reduce
>> the odds of needing to manually break a stale lock.
>
> For now they are atomic, but not transactional. Meaning you can get  
> out
> of order. 2 pushes are modifying branch.py-*.weave, they each create a
> temporary file, and then one wins.
> And if they both modify branch.py and clone.py, one might win one, and
> the other would win the other.

Hm, I see.  Hence the need for the write lock. :)  Sorry, it took me  
a little while to digest what was going on.

I think simpler is better here:  We record tracking info in the write  
lock (email, IP, timestamp) and provide a way to explicitly break the  
lock.  Maybe if an operation fails because of a write lock, and that  
lock is pretty old (by some arbitrary standard), bzr could hint to  
the user:

     The branch was locked by <robey at lag.net> 5 hours ago.
     If the lock is stale, you can break it with: bzr break-lock

But no magic of trying to guess if the lock should be automatically  
broken, etc.  Stale locks should be relatively rare.

robey