I am happy to announce that I have just released MacHg 0.9.17.
MacHg 0.9.17 greatly improves external diffing and merging tool support. You can now simply select a diffing tool and separately a merging tool from the drop down menus in the advanced preferences of MacHg. MacHg now directly supports the following external tools: FileMerge, Araxis Merge, P4Merge, DiffMerge, kdiff3, DeltaWalker, Kaleidoscope, Changes, DiffFork, BBEdit, and TextWrangler. Additionally, more development has gone into NSTask handling, which solves several bugs in this critical area. Mercurial extensions are now only referenced when needed for a small speed boost. MacHg 0.9.17 also updates the included version of Mercurial to the latest Mercurial 1.8.1. Other improvements in ssh configuration and disclosures have been added. In addition, other small fixes and enhancements have been made including fixing bugs #76, #98, #122, #163, #179, #198, #209, #211, #212, #214, #217, #218, as well as other unreported issues.
As in the other recent versions it’s now really close to version MacHg 1.0.0. This version puts on yet more polish. For end users, the notable new changes are the fact that most of the common external diffing and merging tools are now directly supported in MacHg. This was probably the second most requested issue users seemed to have.
As you can see from the following picture you can now simply just choose a tool…
Most of the external tools can be anywhere on your machine, but a few of them need to be in specific locations to run (e.g., p4merge). (MacHg tells you if you need to put a tool in a specific place.) Thus to use an external tool just download it from the publisher’s website. Then install it somewhere on your machine, then run it once and quit it (to ensure that OSX knows where it is). Then finally select that tool in the drop down in the advanced preferences in MacHg and do your diffs and/or merges with it.
(On a personal note, of the free tools I still think FileMerge is the nicest, but that’s probably because I am used to it. Certainly, p4merge is also quite nice, and DiffMerge is nice as well.) Also note that currently the only tool I am aware of which does binary merges is Araxis Merge.
If you are an author who makes an external diff or merging tool and would like me to add direct support for it to MacHg, please contact me. Ideally, if you are an external tool author then the diffing and/or merging scripts should live inside your application bundle, since client tools, like MacHg, can look up the location of your application bundle via the bundle identifier and thus get the direct path to the script. This means that the user only has to have the application installed somewhere on the machine and then the client, like MacHg, can do the rest (i.e. there doesn’t need to be any further configuration or installation of tools.) By the way, a notable exception to this rule is that for Kaleidoscope its users need to install the command line tools before MacHg can use this external tool. (MacHg recognizes this and puts up an alert telling you that you need to install these tools. Of course, this step isn’t that onerous, but anything we can do to easy users’ configuration hassles is an improvement.)
Also I would like to thank the authors of all of the commercial external diffing and merging tools used in MacHg for kindly providing me a license so I can do testing! Thanks guys!
Another change here is that the password option has been taken out for ssh. One might think this is a retrograde step; but actually it had never worked correctly in the first place. It turns out that in all my testing, I had my ssh keys set up in such a way that the password was ignored and it just worked. Due to a new warning in Mercurial 1.8.1 I realized this wasn’t working like it should. It turns out that it’s a security risk to pass the password through to another tool by embedding it in the URL. (This is due to the fact that if there is anyone else on your machine, they could simply read the password from listing the processes running on the machine. For this reason the creators of ssh tried to make it very difficult to pass a password or accept passwords through the normal channels, hence forcing clients to use more secure channels.) The gory details are in the email thread here. Thus, in the end I found that the best thing to do is ensure the client has their ssh keys set up correctly and non-interactively in order to do clean ssh connections.
Right on to the final MacHg changes before 1.0.0.