Archive for MacHG

Still here…

Hi All,

A quick note to say that I am still here. Unfortunately with my day job I have been working on a skunk works project that took up all my work time and it took up all my outside free time as well. And, it has been going on for a while like this. The good news is that I am almost through with a conversion of MacHg from using GarbageCollection to a version based on ARC. Hopefully I will be releasing it soonish…

Cheers, Jas

Comments (3)

MacHg 1.0.0 Beta Released!!

I am extremely happy to announce that much work has happened on MacHg in the last 4 months. In fact after the 25 previously shipped versions of MacHg I have released, I am just about ready to launch a very complete version 1.0. (This corresponds to the original complete feature set I considered to be a mature and very complete client.)

There have been many, many changes in these last months. However, the major changes can be grouped into the following categories:

  • Major work on the sidebar (MacHg now supports repository grouping for sub repositories and sub repository support, multiple selection dragging, deleting, badge counts, moving, and copying to other documents.)
  • File outline views, and flat file table outline views, in addition to the browser view. (This was a much requested feature.)
  • In product, sub-line, side-by-side and unified differences. (Another highly requested feature.)
  • Hunk level commit selection when committing or amending a commit. (Another frequently requested feature.)
  • Revamping the menu layout, adding better support tags, bookmarks and branches, etc.
  • Added a new AlterDetails sheet to allow easily changing commit messages / commit authors / commit times.
  • Refactored the GUI to more uniformly use my own concertina views.
  • Removed dependence on BWToolkit for compatibility with newer versions of XCode.
  • Many, many bug fixes, additions and improvements.

If you use MacHg could you download this version and give me feedback on it. I am looking for show-stoppers and new things that crop up as a result of these changes. I should be releasing MacHg 1.0 in maybe a week’s time… During this next weekend I will be adding the documentation for the new features and recording screen casts on new functionality, etc.

You can download the beta version of MacHg here:

Thanks, Jason

Comments (5)

MacHg 0.9.24 Released!!

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

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

MacHg 0.9.24 updates MacHg to fix Lion compatibility issues, and also updates the underlying Mercurial to the latest version, 1.9.2. There are a number of other nice fixes in MacHg 0.9.24. Take a look at the full change log for details!

As a personal note, sorry for the 3 month delay in development here. My real world job has been very busy and demanding, and I haven’t had as much time to devote to MacHg as I would have liked. However, the roadmap is still very much in progress…

Cheers, Jason

Comments (2)

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)