I'm sponsoring this case for myself; the release binding is Minor.
As part of "Mercurial integration" (PSARC/2006/417), hgmerge(1) was documented as Committed. This project specifies the removal of that utility. No version of Solaris has shipped yet with that interface, and the project team asserts that the change is non-controversial. This utility was essentially a configuration file masquerading as a shell script. It contained a list of three-way merge tools and attempted to execute them, in an order of preference hard-coded into the script, until one was successful. Shortly before the release of mercurial 1.0 hgmerge(1) was removed from the distribution, because the core mercurial code acquired basic three-way merge functionality (a la RCS merge or diff3) in addition to a new configuration section for external merge programs. These two additions obviated the need for hgmerge(1). Given that the only three-way merge utility listed in hgmerge(1) which currently ships with Solaris is diff3, it's unlikely that many users on Solaris derived any benefit from its being there. They are much more likely to have configured a specific external merge program (such as one being developed in-house as a replacement for filemerge(1), gpyfm(1)); that configuration will continue to work. For those that had installed meld, kdiff3, tkdiff, or one of the others listed in hgmerge(1), and had no merge-specific mercurial configuration, they will have to tweak their configuration (~/.hgrc) to tell mercurial to invoke the utility of their choice. The project team will make announcements on all the appropriate aliases. In addition, although hgmerge(1) could be used as a standalone utility, it was likely rarely used as such. The project team doesn't feel that the class of users who might have used hgmerge(1) standalone is of a significant enough size to keep the utility around on that basis. Danek
