On Sun, Oct 18, 2009 at 2:47 PM, Sune Foldager <sune.folda...@me.com> wrote: > Steve Borho wrote: >> >>> Since 1.4 will include extdiff 3-way we should (despite the feature >>> freeze) >>> at least change "our" (not implying ownership) visdiff code. supporting >>> full >>> 3-way is a mouthfull, but we should support and respect the $parent1, >>> $parent2 and $child tags. We'll just not use $parent2, then, which is ok >>> (it >>> says in extdiff that if you use $parent2, the diff program _must_ handle >>> the >>> argument being left out, for 2-way mode). >>> >>> I can make a patch ASAP. >>> >> >> I agree. 0.9 should support 3-way diffs out of the box. >> > > Well, ok, there are two levels at least: > 1. Since 1.4 supports 3-way syntax, we should not (as is the case now) fail > invoking the differ when it's used. This was what I was talking about > mostly, as it's a rather small change.
Right. But I intend to change the kdiff3 opts in the default Mercurial.ini file so that these arguments are there by default. So this is a minimum. I'm also debating about whether to make vdiffnowin the default. > 2. We could roll in full 3-way support, essentially moving a lot of my newer > code in from extdiff.py, but this will take a bit more effort. A lot more work, but doable. > Another thing: Remember I asked why not use shellquote on POSIX? Well.. .I > looked into things and tested it a bit, and now I would ask: Why use > shellquote ever, and not just always pass in a list of arguments? On Windows > this will be quoted automatically by subprocess, so I think this would be > even better and require less code. If it works, I plan on back-porting that > approach into extdiff.py. I cannot find the reference right now, but there were diff tools whose command lines were essentially impossible to parse correctly into argument lists. They do things like /firstname:"My Changes" which just gives shlex nightmares. I've been planning for a while to leverage Mercurial's merge-tools code to auto-detect diff tools, so we don't have to support all these loopy extdiff configs out there, but it didn't make it into 0.9. > Also, we should maybe think about how much we can possibly break down > extdiff into separate functions to reuse in visdiff.py sometime later on. Of > course it's much easier to change TortoiseHg than get through to Mercurial > :-p. I think Matt would take a cleanup like that for 1.4. Worst case we have to carry it in our code till the next release. -- Steve Borho ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
