"Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: >> 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?
Right, you can propagate changes in all directions. There is also no "output" buffer, you can choose to save any of the 3, the one you *want* to save, is the one that isn't a temp file... If you want a good example of what's been giving me hell, create a test case where one side of the merge removes a line, and try and merge it. You'll note that you have to remove that by hand, to make the merge correct. The upshot of this is, when I did a test merge against onnv-gate with meld, merging your changes for license uniquification (and fiveash's wx changes, but less so) is something I got wrong over and over until I gave up and used something else. The navigation in meld didn't even jump to those lines either with up/down arrow, or the little coloured blocks! >> 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. I think the priority settings, and all that, are documented by Mercurial. Yes, if we can restore gpyfm to the point it's downloadable and usable, we should provide a means to make it easy to run. I've been hoping that dmarker would put his gpyfm workspace into a separate workspace under scm-migration/ (since his code has more fixes than what is in onnv-scm), and either he (or I, given time) would cause it to be buildable on its own, and possibly packaged. My experience thus far suggests that keeping gpyfm around would be a good thing, just not something we can block on, I certainly don't want it to vanish entirely. Dave should feel free to consider that a call to arms (as long as the gate stuff is done too) :) -- Rich
