[PATCH 2 of 2] Reorder rename operations to minimise risk of leaving repository in unknown state

[Laurens Holst]

Op 29-9-2009 11:48, Adrian Buehlmann schreef:
> On 29.09.2009 10:50, Laurens Holst wrote:
>    
>> I don’t think that’s true. That would only be the case if AVG already
>> locked the file before step 1, but that is not the case. We established
>> this in the discussion in TortoiseHg issue 580 [1].
>>      
> No. You present your view of things.
>
> "We" established nothing.
>    

Actually, it was a discussion to which multiple people contributed. And 
Steve Borho contributed the final piece to the puzzle in comment 23, 
leading to the logical conclusion that, under the assumption that the 
Windows documentation describes the actual behaviour, this must be the 
case. Delete and rename share permissions as they are tied together 
through a single flag, so the file must have been opened inbetween the 
rename and the unlink.

But if you have actual arguments, let’s hear them. Would be more useful 
than this… personal attack, or whatever it is. Snide non-constructive 
remark at the least. Way to contribute to an atmosphere of 
collaboration. >_<

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurens_nospam.vcf
Type: text/x-vcard
Size: 107 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20091002/3c925410/attachment-0002.vcf>