Hey all, I'd like code review, or at least comment, on:
476 changes for move from gpyfm http://cr.opensolaris.org/~richlowe/scm_476 And with the file list ordered such that actual changes are first: http://cr.opensolaris.org/~richlowe/scm_476-ordered This removes gpyfm from the packaging, build, and source tree, and adjusts various other things to cease mentioning it. This changes hgsetup to use the Hg 1.0 method of configuring merge tools. The default configuration is to use filemerge, if that can't be found, use meld. (this decision based largely on the fact that meld and filemerge are so different and that, as below, I can't come up with a way to invoke meld that I, at least, don't find loathsome) Meld is set up as in mercurial's contrib/mergetools.hgrc. I'm not sure that's the right thing to be doing. From what I can tell, meld's 3-way merge is not really 3-way, but 3 file (it doesn't do anything special with the ancestor, it just sticks it in a 3rd diff pane), I've found that nothing but annoying. I'd especially like input from someone who actually uses and is familiar with meld about how we should run it. A two way merge between local and other? (and in that case, in which order?) hgsetup -m is retained, with effectively the prior behaviour, such that you can override the defaults (in the absolute) with a tool of your choosing. This also means that assuming hgsetup is run with -m (and doesn't point at gpyfm, of course), you can keep using 0.9.5 after these changes. (as you could if you updated your ui.merge in general). I'm hoping that dmarker is going to put gpyfm as he has it in a separate gate under scm-migration such that it still exists. I'm also hoping to move gpyfm bugs to a separate category on bugs.grommit.com, such that they're out of our way, but don't vanish entirely. -- Rich
