On Thu, Aug 7, 2008 at 5:23 PM, Adrian Buehlmann <[EMAIL PROTECTED]> wrote: > On 07.08.2008 18:11, Peter Arrenbrecht wrote: >> On Thu, Aug 7, 2008 at 11:12 AM, Adrian Buehlmann <[EMAIL PROTECTED]> wrote: >>> I've created a new page on the Mercurial wiki, trying to shade some light >>> on what openers do and how they are used in Mercurial: >>> >>> http://www.selenic.com/mercurial/wiki/index.cgi/Opener >> >> Thanks Adrian, shall try to look at it tomorrow. I asked on #mercurial >> about whether this bug would affect the hardlinks created by `hg >> clone` and ThomasAH thought not (as I do). Only files outside of >> .hg/store/ hardlinked by operations such as `cp -al`. So unless your >> page or my own digging into the code is going to convince me >> otherwise, I still think this bug is not that critical on Windows. Not >> sure I can do this in time, though, as I'm going on vacation again >> Saturday. > > I never claimed it to be critical! > > I just see no point in running the risk of letting it > *get* critical, if that damn thing has already been fixed > weeks ago! Who knows what dirty tricks new extensions > will play? And why let yet another release escape > that does not contain the fix for that bug? > > Again, Mercurial would certainly *not* have released > a new release *not* containing the fix for that bug, > but THG has done exactly that.
For the record, I've withdrew from the discussion on this topic, and shall refrain from further comment. > It looks like some part in the calling code would have > to do modes like "r+" or "rb+" or something similar > (did a quick search when Benoit pushed that cset then, > I think mq does that). > These modes look at first sight like they were read only. > But they aren't! They modify the file! > > It was just quite shocking for me to see such a big botch > in such a central part. The code that must be executed > in the opener when it is a write access just neglected > a whole bunch of cases that actually are write accesses too. > > Funny thing is, while I was doing my long filename > patch odyssey (see mercurial-devel list) I stared > at that code there and thought "damn, if that test > is wrong, we have a mess with the hardlinks", but > then moved on because I thought the Mercurial top > shots would have thought that very well, when they > hacked that sensitive thing. And bam! A few days > later Benoit pushed that cset (note that my patches > would not be affected by that because I deliberately > don't look into modes -- for good reason). > > Mercurial and the current extensions seemed to have had some > luck until today that nothing vital was hit yet, > but facing the theoretical possibility makes my gut > feeling to decide to fix that damn thing ASAP. > > You might think I'm too paranoid about this one, but > I have been hit in the past enough times for *not* being > paranoid enough. > > I would also like to point out the even if the THG > people claim they do only a GUI thing, their package > still contains the core Mercurial and probably > 90% of the Windows people which want Mercurial will > download and install THG. > > In light of that, I think it is also a bit unfair to the > Mercurial team, to ship that bug in a newly created > binary. After all, they have fixed it! They just didn't > get around to rubber stamp it with another release > tag! (which doesn't mean you can't trust crew-stable). > > So, you see, we have wasted a lot of time talking about > this stupid issue here. Without any need at all. > It would have been a simple thing to take crew-stable. > Or at least not trying to tell me how foolish and > arrogant I am in daring to criticize THG for not doing > so! > > I also don't think you need to look into this code > Peter, so please enjoy your holidy. It won't make any > difference. > > Simple recommendation from my side for next time: > If you want to do an async release of THG next time > and there are important fixes in crew-stable of Mercurial, > take crew-stable *or* wait for the next rubber stamped > Mercurial (if you still want to have a rubber stamped > one). > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tortoisehg-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
