release status - land new features before monday

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
> 
> ...
> 
>> I don't know how you are guys, but I'm still depressed by new dirstate
>> format: it's completely unusable on win98,
>> it has many bugs related to add/move files in working tree,
>> and it every time want upgrade, even if I don't want this.
>>
>> /me want back to knits+tags.
> 
> We are still using knits :)
> 
> I think Matthew Fuller was working on a patch to allow you to disable
> the upgrade request.
> 
> Also, win98 really isn't a "supported" platform because of problems like
> this... But you could actually just disable the OS lock if you wanted.
> You could make the read lock a no-op, and just take out a LockFile on
> write locks.
> 
> We are already guarding against multiple writers because we are taking
> out a LockDir on .bzr/checkout/lock, so we don't strictly need an OS
> lock on .bzr/checkout/dirstate.
> 
> At this point, locking 'dirstate' is more of future proofing, because we
> eventually will try to read just portions of the file, rather than
> always reading the whole thing. And that starts to get dicey if the file
> might be changing underneath you.

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?

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. 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.

How it sounds? Like a madman's mumblings or this approach make sense?

[µ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGHRs0zYr338mxwCURAn+5AJ90BPz1PnE6cqeIa6NAteEI33ra1gCdHidK
DVKLGrP7zp5ZR6aJaGRHeCU=
=ypvd
-----END PGP SIGNATURE-----