Short summary: 1. dmarker: save us! 2. richlowe: looks right.
More or less useful comments inline below. --Mark > 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. This looks right, and I played with it, and it seems to behave correctly. Since I upgraded mrliberal to snv_89 this morning, I'm even using it with hg 1.0. > 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) I tend to agree, at least based on the trival, contrived example I setup. I simply added a single line in the same place in multiple workspaces, and the merge was surprisingly nonintuitive, as was saving the result. I have not explored whether there's a better was to set this up. I repeated the example with filemerge in my path, and was much happier. > 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. The third file is the output file, right? The one in the center pane? It's initialized to be the ancestor, and then you click on the left or right pane to propagate diffs? The hideous part seemed to be that you could propagate in both directions, in other words modify the new, old, and merged files? > 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. Me, too. And at the point where you can download gpyfm, we'll need to provide instructions on how to configure .hgrc to work correctly with it. And probably provide more explanation oof the priority settings there. But for now, I think this is OK as it is. --Mark
