On Thu, 2008-04-03 at 14:34 -0700, Danek Duvall wrote: > On Thu, Apr 03, 2008 at 10:09:42PM +0100, John Levon wrote: > > > On Wed, Apr 02, 2008 at 01:43:33PM -0700, Danek Duvall wrote: > > > > > > I guess it's ok, but I'm confused -where did you stash hgmerge? - it's > > > > deleted from prototype_com. > > > > > > hgmerge is gone. I need to run a fasttrack for that. > > > > How do we specify the merge binary now? The xvm-gate tools have a > > modified hgmerge that finds the 'merge' from RCS. How do people merge > > sensibly with the new packages? > > It all works as it did before, except that the "hgmerge" program simply > isn't shipped. It seems to still fallback to "hgmerge" if it can be found, > and you can still set the "HGMERGE" environment variable, or the "ui.merge" > hgrc variable.
We use the following rules: - HGMERGE, if set - then the tool matching a pattern in [merge-patterns], if found - then tools by priority: - ui.merge has the highest priority - followed by tools specified in [merge-tools], with given priorities ?? - the 'hgmerge' script has the lowest priority - tools that can't be found are dropped - list is narrowed based on gui, symlink, and binary support - if all else fails, we use the new internal:merge And the last is basically equivalent to RCS merge. So you don't really -need- an external tool any more. Further, in most cases, we'll attempt an internal merge first, before actually running the external tool. Also, there's a set of default merge tools in contrib/mergetools.hgrc. A packager should put this in the appropriate global place for their system, and then most tools will automatically work out of the box. The configuration here is incredibly simple - many tools have a single line of config like this: gpyfm.gui=True -- Mathematics is the supreme nostalgia of our time.
