MacHg 0.9.22 Released!

I am happy to announce that I have just released MacHg 0.9.22.

You can get the latest MacHg from the downloads, and you can view the latest release notes here.

MacHg 0.9.22 is primarily a bug fix release. There was an issue where if you double clicked on a file without changes in the last version MacHg would crash. This is now fixed. There are a number of other nice fixes in MacHg 0.9.22 but nothing critical. Take a look at the full change log for details!

Cheers, Jason

Comments (3)

MacHg 0.9.21 released!

I am happy to announce that I have just released MacHg 0.9.21.

You can get the latest MacHg from the downloads, and you can view the latest release notes here.

In MacHg 0.9.21 I think I have finally fixed the various NSTask related problems. Previously NSTask would intermittently hang, or just drop tasks. But only fairly occasionally. I had gotten to the stage where I could reproduce the problems in small code samples and had sent these small projects to the cocoa-dev list. Finally I have managed to fix things by switching to a drop in replacement of NSTask called TLMTask written by Adam R. Maxwell (who writes the TeX Live Utility) (Adam has been extremely helpful in private emails about issues to do with TLMTask,)

So this completes the promise in the last blog post. There are currently no critical bugs I am aware of stopping me releasing MacHg 1.0.0. I will see if any problems crop up in the wild with MacHg 0.9.21 and if not this latest version will become version 1.0.0!

Cheers, Jason

[Update : fixed Adam’s name as Adam pointed out]

Comments (2)

MacHg 0.9.20 released!

I am happy to announce that I have just released MacHg 0.9.20.

You can get the latest MacHg from the downloads, and you can view the latest release notes here.

MacHg 0.9.20 now continually reports the progress of long running operations such as clone, push, pull, incoming, and outgoing; adds an ‘Open With…’ menu item; adds a ‘Scroll to Changeset…’ menu in all log views; updates the bundled Mercurial to 1.8.2; and includes a number of other fixes and enhancements.

I really like the new ‘Scroll to Changeset’ feature. You can just hit cmd-L to go to any changeset and it’s available anywhere you see a list of changesets. Having progress for long running operations is also something that has been requested for a long time. With the NSTask changes in recent versions of MacHg this has now been possible.

Unfortunately, MacHg is still having very occasional and intermittent quirks with NSTask. After several posts to cocoa-dev and some examples posted there where NSTask is just dropping tasks I am investigating other options in ernest. I can’t go MacHg 1.0.0 until I fix this, but happily I have another option on the horizon right now.

In my testing this new alternative is working almost perfectly. I haven’t seen any dropped NSTask’s at all. However, the progressive progress updates that I just added in MacHg 0.9.20 are not yet working with this alternative method. Once I have this last kink ironed out, I will hopefully be releasing another version of MacHg very shortly (within the week) which fixes the very occasional and intermittent missing or hung NSTasks.

Cheers, Jason

Leave a Comment

MacHg 0.9.19 released

Darn… Well release 0.9.17 almost went off without a hitch…

However, in making the changes in MacHg 0.9.17 so that everyone would get the latest enhancements to the diffing and merging tools as well as the speedup for the extension handling in Mercurial I choose to upgrade the support folder for MacHg. MacHg would detect when run if the most advanced version previously run was before 0.9.17 and if so it moved ~/Library/Application Support/MacHg to the trash and of course just regenerated this folder. This worked fine for me, but it turns out that I made a decision (a bad one), way back at the start, to store the default location of the repository list in ~/Library/Application Support/MacHg/Repositories.mchg. So for users who just used the defaults, I had moved their list of repositories to the trash. !!Opps… Not good!!

Anyway MacHg 0.9.18 fixes this by moving only ~/Library/Application Support/MacHg/hgrc to the trash. In a future update I’ll make sure Repositories.mchg is handled either in the documents folder or in a better way.

MacHg 0.9.19 is also a small point fix to make the amend option to commits work again for those people who don’t have the mercurial queues extension turned on by default.

Sorry about letting this slip through…

(This brings up the point. I think I need a list of beta testers. I’ll send out a message about this to the news group, or send me an email at about being a beta tester.)

Cheers! Jas

Leave a Comment

MacHg 0.9.17 released!

I am happy to announce that I have just released MacHg 0.9.17.

You can get the latest MacHg from the downloads, and you can view the latest release notes here.

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.

Cheers, Jason

Comments (2)

MacHg 0.9.15 released!

I am pleased to announce the release of MacHg 0.9.15!

Downloads at:
ReleaseNotes at:
Sources at:

Release 0.9.15 significantly revamps and improves the push, pull, incoming and outgoing sheets; significantly revamps and improves the server configuration sheet; now always stores passwords in the system keychain; adds support for handling of google code respositories and svn repositories; has “under the hood” improvements in the way disclosures are handled; and fixes or addresses many smaller issues including: #98, #116, #170, #184, #193, #200, #202, and many other unreported issues.

Others who contributed patches to this release (Thank you all!):

  • Kim Hunter
  • Matthew Watson
  • Eugene Golushkov

I really like the changes I added in MacHg 0.9.15. Nothing was critical but there were lots of details and polish that just make things better and more intuitive now. It’s one of the nice things about UI design that sometimes after you implement something and play with it, it’s just really obvious that the new way is better / worse than the old way. And the new changes to 0.9.15 are quite nice if I do say so myself…

Actually I probably could have gone 1.0.0 with 0.9.14, but I still might add some basic sub-repository handling before going 1.0.0. Or, maybe if there are no major bugs with 0.9.15 I will just basically use that to go 1.0.0.

I also wanted to say thank you to all users of MacHg for your excellent comments and feedback!

Cheers, Jason

Comments (1)

History Editing in Mercurial is Standard Practice.

It’s a standardly espoused mantra by some people using DVCS’s that history editing is bad / evil. I don’t agree.

In fact MacHg has sheet interfaces to strip, histedit, rebase, collapse, and amend commits. I use these features constantly. With a little care and safety most intermediate Mercurial users should be using these history editing features too… Or at least know what history editing is and what is possible. If you standardly do a clone before editing history, there is zero danger of loosing anything since to undo you simply revert to the clone.

Personally, I tend to work on my code for a while adding, polishing, moving bits around and then push stuff in a clump. I do a lot of “history editing” before I push. My typical workflow, and I would assume that of others, involves a lot of development time consisting of small little tweaks. I often commit before I compile just in case I mess something up. Then I start testing the new code. I will often then find some simple typos, or maybe missed including something. Then I simply do an amend commit. Once I have things compiling, the next changes either go in their own commits if they are big, or are amended into the previous commit if they involve simple small oversights.

Even though amend is not a standard part of Mercurial, I added amend specially into MacHg since it’s very useful. It’s available in the advanced options of the commit sheet: The Amend Option

(I will often use histedit to move things around until they are in a nice order for later historical understanding so that when I or someone else looks back 6 months from now I / they have some hope of following what I was doing. In fact I often don’t worry too much about the commit message. I often go back once things are moved around and organized into shape and change the commit messages to something detailed and sensible… Of course I do this on the stuff I haven’t yet pushed to the wider world. Note to do this editing I often make throw away clones just in case something goes wrong with the history editing process, so I can just step back to where I was. At some stage it would be really nice to have a wider undo, rather than the limited rollback we now have… But thats the topic for other emails…)

I commit early and very often. But many of my commits are not logical chunks or they go down blind alleys etc. Thus history editing is really really useful. In fact one of the largest examples of this close to home is the Mercurial python source code itself. The commit history for the Mercurial project itself is quite clean and the quality level of the patches before they are applied to the mercurial sources is quite high. There are very few: “Opps, include that header”, “Opps change the spelling here”, “Opps, make sure it compiles under linux”, “Opps, make sure it passes this test”, etc. sorts of commits in the Mercurial source tree. Thus in one way or another the ethos behind the Mercurial project’s revision history is a clean one.

Consequently it appears to me that its somewhat iniquitous to see that the Mercurial project itself keeps a very clean history where the patches sent in have obviously been history edited in one way or another, but tends to espouse the position that history editing is evil, and all you people just keep whatever intermediate erroneous commits in your repository because its good for you. (even though we don’t keep them in our history ourselves…)

In any case the clear shining example here is that the Mercurial sources themselves are clean from the “opps” sorts of commits. So somehow users would also like to have similarly clean and followable commit histories. You do this through amending, rebasing, collapsing, reordering, and rearranging your changesets.

When you are starting out with history editing, make sure you make a clone of your repository before you do the edits just in case you mess things up. Actually the most dangerous time for users in reference to history editing is probably not when you are starting out, but when you get comfortable but are still not yet really experienced, and things are going fine and you have done lots of edits before, and “Well I will just skip that step of making a clone, and I’ll do all the edits at once instead of in steps so its a bit quicker and, opps…” Also most people on OSX will have time machine running and backing up there repositories, so in case of a major stuff up you are at most going to loose an hours work. (Note this has never happened to me.)

I’ll try to do a screen cast about history editing at some stage soon.

Comments (2)

MacHg 0.9.14 released!

I just released MacHg 0.9.14 which adds the ability to drag and drop from the browser to the dock or finder; improves importing and exporting patches; fixes a major bug to do with very heavy processor load and visual flickering; updates the Mercurial bundle to 1.7.5; handles the new security model of Mercurial 1.7.5; includes TrustedCertificates for https connections; fixes handling of external diff tools for the users who were having issues; and fixes or addresses many smaller issues including: #136, #148, #158, #159, #163, #164, #173, #178, #179, #181, #185, #189, #192.

It feels good to get this version out the door since it fixed that very infrequent but fairly serious bug of maxing out the processor and causing page flicker. It was really hard for me to solve this bug since I couldn’t reproducible it. But finally in the end through users help, I found an example which could reproduce the problem. And happily with that I solved the issue.

I will also comment and say that the new security changes in Mercurial 1.7.3 & 1.7.4 are for the better but adding the corresponding support in MacHg was not without some pain. Most of the changes which occur to Mercurial these days are pretty much internal changes but the security changes in handling https were definitely changes that had to be accommodated by GUI writers like me.

It was also good to nail that complaint which I also couldn’t reproduce about external diff tools not working correctly, since they worked fine for me… (It turned out that the users didn’t have /usr/local/bin on their path, whereas I did through /Users/jason/.MacOSX/environment.plist)

Anyway, with those changes, things are coming along really nicely. MacHg 1.0 is nearly here…! 🙂

Comments (3)

Thanks Joe!

I want to thank Joe Workman who is a user of MacHg. He designs lots of stacks for RapidWeaver + Stacks. I use Rapidweaver for doing the MacHg website and it’s pretty efficient. I had always been meaning to play with some of the javascript tools to do fancy things, jQuery, etc. However, Joe was really nice and donated all his various stacks to the MacHg cause and so now I am using a few of them in the site. And… well… I didn’t have to learn jQuery (at least not yet…) That rotating log of mini-screen shots on the front page now is done using Joe’s stack Gyro! Its very nice to have something like his stacks which are just smooth and easy to use. So, Joe, thanks!

Leave a Comment

Unified diffs and GUI clients

Recently a user of MacHg asked how to display the differences in a file inside MacHg.

I personally have an opinion on this which differs somewhat from the established dogma. Thus I will outline my position here so I don’t have to elaborate it elsewhere, and hopefully it will make other GUI designers at least think about this issue.

The situation right now is that almost all GUI clients for Revision Control Systems (RCS’s) show differences “in application” through unified diffs. This is done because unified diffs are rather short and compact. But unified diffs don’t show all the surrounding code; and really in a large section of code with several changes, it is very difficult to immediately see what changes are occurring.

In fact, every single external GUI diffing program that I have seen has as default a side-by-side diff. (Some programs allow as an option, unified diffs, but it’s definitely something which is not the main thrust of the program.)

So, why does every single program that is dedicated to showing differences, display differences in a way different to that used inside almost all RCS GUI clients?

The reason is that most people sooner or later are forced into being able to recognize unified diffs. And after much exposure they begin to expect to see unified diffs, even though they are a very suboptimal way to view diffs.

Why do people get used to unified diffs? The reason is that since unified diffs are the raw format for diffs and are plain ASCII, they can be easily emailed around and inspected by people using tools which have nothing to do with diffing (eg email clients, text editors, displaying text on a web page, etc). In fact in some lists, sending unified diffs is the default way to exchange information, since in email ASCII is the lowest common denominator. (For instance, the mercurial development mailing list uses unified diffs as an interchange means of publicly discussing proposed changes.)

Of course, email is a very convenient interchange system, so developers are reading these unified diffs all day. Thus when some developer goes to create an RCS GUI client, they naturally put in the stuff they are working with all day, eg unified diffs.

But let’s take a look at what happens here in a screen shot from another RCS GUI client. (Note: I am not singling out this client amongst others, since many other clients do exactly the same thing.) However, of the overall window size (892 pixels x 689 pixels) the part which shows this unified diff is quite small (624 pixels x 192 pixels). Thus, just 19.5% of the window size is dedicated to showing the differences from one version of a file to the next in a semi-obfiscated patch interchange format.

I think its just sub-optimal.

(Of course for some die hard developers who eat, sleep, and breath unified diffs, maybe having some in program unified diff display is semi-convenient. However, to a large degree such people tend to use the command line in any case, so dedicating GUI features for them is futile.)

In this day and age of 32 inch LCD monitors, I think GUI RCS client programs need to live a little and somehow encourage the showing of diffs in the format that well… all dedicated GUI diffing programs use. Ie right now, use a very fast dedicated client or in-application code which shows the diff in a side-by-side format with full context in a large window.

(That said I have had more than a few requests for this feature in MacHg. And I try and do what users want… So maybe later I will have to toe the line and add these unified diffs into MacHG… But I am resisting for now…)

Comments (1)