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

[Laurens Holst]

Op 2-10-2009 12:04, Adrian Buehlmann schreef:
> The only personal attack I can find in this thread is the second part
> of _your_ post I quoted above.
>    

Okay, your post and previous comments directed towards me were the 
epitome of reason.

> I find it highly non-constructive to present conclusions as being
> accepted and agreed by everyone if they are not.

I’m sorry, but you still haven’t provided a *single* argument why that 
conclusion would be false. In the contrary, you continue to ignore my 
argumentation…

> Most people here don't
> have the time to meticulously verify such dubious asserts.
>    

…and pretend it is ‘dubious’ without any explanation as to why. And you 
are accusing ME of misrepresentation? My conclusions and what lead me to 
reach those are well documented in earlier posts. You are the one here 
trying to steer the discussion by spreading FUD.

I am trying to discuss based on facts. If you disagree with the logic, 
give me arguments, do not post non-constructive accusations that only 
serve to offend me.

> But they serve to lead the discussions onto a wrong track, by building
> on false assumptions. Which is a waste of time.
>    

And again, you are doing exactly what you accuse me of.

> I find it even more non-constructive to publicly blame Mercurial for
> errors of the sort of "Eeek! It corrupted my repository! I lost my work!"
>    

Then don’t make a fucking public bug tracking system if you can’t handle 
users complaining about data loss. And get some glasses, because you are 
definitely misrepresenting me here. I simply mentioned the facts, 
because I did get a pretty nasty failure. I am not fucking blaming 
anyone, I even explicitly said so in that issue 580. I am looking for 
ways to avoid it.

What do you want, people should only write positive things in bugs? 
Present everything with a silver lining so as to avoid any potential 
perception that Mercurial isn’t 100% perfect?

I’m sorry, I’m starting to lose all my patience here.

> Back to to the problem at hand:
>
> I agree with you in the sense that I fear these "no-cost" file system API
> breaking virus scanners seem to start to get a very serious problem
> for the use of Mercurial on Windows, if lots of people just install
> them without being aware of the consequences.
>    

Right. That’s my opinion too, this is why I filed the bug, and this is 
the reason I am trying to see how this problem can be avoided instead of 
just blaming AVG and harassing anyone who files bugs about it.

> The creators and contributors of/to Mercurial have already invested
> at lot of time and energy to adapt to the numerous extra quirks the
> Windows platform is presenting. But having to work around processes
> that hard-lock Mercurial's private files at random times is really
> asking for taking this to new heights (or, rather, lows in this case).
>    

Well, it is only a small change in the order of operations, I don’t 
consider it a huge workaround, and if there is an improvement in 
reliability as a result of it I don’t see the problem.

> I would appreciate if an AV-scanner fan could test and see how
> Mercurial runs together with the new gratis virus scanner
> that Microsoft just released these days. If that scanner does the
> same random hard-locking of files, then we will have a very serious
> problem indeed with the Windows platform.
>    

I already uninstalled AVG a couple of days ago and am trying this new 
Microsoft one (it was recommended @ work as well), but I’m not using 
Mercurial on a day-to-day basis at work so it might take a while for me 
to run into issues, if any.

~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/918f90fe/attachment-0002.vcf>