release status - land new features before monday

[Martin Pool]

On 4/12/07, Alexander Belchenko <bialix at ukr.net> wrote:
> You explanation leads me to one *wild* idea: bzr should delete the dirstate file
> before write new content, in following steps:
>
> 1) remove dirstate file (or rename it to dirstate.old)
> 2) write new dirtstate content in some temp file, like dirstate.XGT9h or dirstate.new
> 3) then rename temp file to 'dirstate'
>
> Something like we did with old locking scheme based on LockDirs.
>
> I don't know how Linux will works in such situation:
>
> 1) one process read dirstate file
> 2) another process delete dirstate file
>
> On Windows this combination will raise PermissionDenied in second process,
> and this exception could be used as some sort of lock! And anyone process
> cannot read dirstate until another process will not finish write.
>
> I.e. any client could read dirstate without any OS lock, but when someone
> want to overwrite this file, it should delete it first. To prevent another
> process to read incorrect data.
>
> If I understand correctly how Linux remove files currently in use,
> processes that read dirstate will continue to use old copy,
> and process that want to write will create new file, not mixed with
> previous one. Is it correct assumption?

That's correct.  I like the sound of this approach.

I talked about this with Robert and he pointed out that if the process
is interrupted you will sometimes need to clean up or cope with.  For
example a new reader may come along when the file has been moved away
but the new one has not been inserted yet; in that case it needs to
find the old one and keep using it.  I think these can be resolved but
they'd need to be thought through carefully.

We may also accumulate leftover aborted new versions and would need to
clean them up eventually...

It would be nice to somehow make allowance for testing the Windows
approach on Linux to make Alexander's life easier. :)  Maybe an option
on the dirstate that manually fails the delete/rename under the
situations where Windows would.  Or maybe it should work the same way
on all platforms.

> Also, if one process want to write new dirstate when another process
> already start to write, it will get IOError because dirstate is not
> exists yet.

I think that would be avoided by the LockDir on the workingtree?

> In the situation when some process start to change dirstate
> and then die, we either have old copy (dirstate.old) and could rollback,
> or broke our working tree (when dirstate is removed permanently),
> so we need to repair it later based on last committed revision.

That sounds like a good reason to always remove it to dirstate.old and
delete only when we know the update has succeeded.

-- 
Martin