branch locking mk2.

[Martin Pool]

Robert Collins wrote:
> I think we have a slightly confusing transport api, which this branch
> has shown up...
> 
> fancy_rename is more of a fancy_replace function IMO, and its use by
> windows and sftp to implement 'semi atomic renames that replace' is
> misleading.
> 
> So I propose that we
>  * rename fancy_rename to fancy_replace or fancy_move
>  * add a 'replace' or 'move' api to transport which explicitly is 
>    not atomic (lowest common denominator) [but is when it can be ] and  
>    which will replace existing files or directories.
>  * define rename as being explicitly an atomic rename - it either
>    succeeds or it does not. Its behaviour with respect to existing files
>    and directories should then be only defined as well as we can:
>      + it may or may not replace existing files.
>      + renaming an empty directory on top of another empty one may
>        succeed
>      + renaming a non empty directory on top of another non empty
>        directory will not etc.

+1

-- 
Martin