branch locking mk2.

[Robey Pointer]

On 13 Feb 2006, at 14:54, 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.

Agreed, +1 in general.

There are still a few "leaks" of high-level implementation into  
Transports.  I guess once Martin's LockFile lands, we can remove  
lock_read and lock_write too.

After staring sideways at fancy_rename, I think this is high-level  
functionality that should *use* Transport instead of being *used by*  
Transport.  I think instead of passing in rename_func & unlink_func,  
fancy_rename really just wants to be passed a Transport which knows  
how to do these lower-level operations.  We could call it  
osutils.replace (or something) and not have it in Transport at all.   
Does that make sense?

robey