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: http://www.jasonfharris.com/machg/downloads/assets/MacHg1.0.0Beta.zip http://jasonfharris.com/machg/downloads/

Thanks, Jason

I just wanted to drop a quick note about the event “Beers with BitBucket…” that the bitbucket team sponsored this last Tuesday the 25th of October in Chicago.

I went along and scored some bitbucket bling: Two free t-shirts and a bottle opener as well as of course far too much free beer (The beer was quite good.) In fact there was enough free beer that by the end of the night after I had left the two t-shirts at a table at one of the after function bar’s there was only one t-shirt left after I picked up my stuff. So obviously the bling was really popular! Still I guess that’s what happens in Chicago “after hours”.

Still in any case I met some really cool people. The bitbucket guys were really chilled. I pronounced “Atlassian” totally wrong and they still liked me Anyway thanks to Atlassian and the bitbucket crew I have a much better idea of their strategic direction and that they are really in this for the long haul and push.

In fact after I came back at around 2am (I know, I know, wandering around downtown Chicago at 2am fending off all the hmm… people who were trying to sell me “stuff”, maybe wasn’t the brightest thing to do…) But in any case I went to subway for some food and one of the bitbucket system administrators was there and of course we got to talking again and he insisted on personally paying for my subway sandwich… It’s just one detail, but I just got the feeling the team of engineers were just genuienly nice people. I get the feeling they really want to do good things for developers everywhere! So in any case personal thanks to Justin and the others!

I should also say the other people who attended were really interesting. Eg I met one of my MacHg users Sean Farley, and he was a really neat guy (He has a really strange Gravitar image, but I gave him some friendly grief over it. (Scraws!)) . Anyway, it turns out he was also a physicist and he knew a lot about Mathematica (my day job), and knew a lot about well a lot of other really interesting technologies. We got along famously…) But in any case I got some extra impetuous to add an annotation view to MacHg… I really have to get onto this.

But all in all it was a really fun night! Thanks to the bitbucket crowd for hosting it. You guys rock!

Cheers, Jas

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

Update: I have changed the name of this extension from ExcludeChangests to BanChangesets. (9-Oct-2011)

Just a quick note to say I uploaded my first published Mercurial extension!

BanChangesets can be used to ensure that certain changesets which are determined to be “bad” by a team can be banned from being repushed to a central repository.

Imagine that you have a team of people working on a mercurial repository. One of the members of the team pushes a changeset or group of changesets to the central repository but these changesets are “bad” for one reason or another. (Maybe some branch was merged when it should not have been, etc. Maybe some nuclear launch codes were accidentally committed, etc.). Ideally this should never happen. In practice it happens all too frequently.

So typically the leader of the project will send out an email saying something like: Please strip the following revisions from your repositories:

162a93e027fdcc6f037c80d185eb201e346da0b0
69cc2b0e47158d1a571a35ec89c5524b084944c9
a4988662d998b8d986bdaec43079475827aa31d0

The problem is of course that in a team of say 20 people someone might have already pulled the “bad” revisions and they may accidentally miss the email, and re-push these bad revisions back to the central server.

The extension ban-changesets is intended to prevent such a re-push of these “bad” changesets.

See the full details here and on the wiki page

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

I am pleased to announce the release of MacHg 0.9.15!

Downloads at: http://jasonfharris.com/machg/downloads
ReleaseNotes at: http://jasonfharris.com/machg/downloads/notes/releasenotes.html
Sources at: http://bitbucket.org/jfh/machg

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

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:

(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.

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…!

MacHg 0.9.12 adds stable graph drawing and large speed and optimization improvements to load times.

I missed releasing MacHg 0.9.12 on Christmas by a couple of days. (But of course family things took precedence and… well… I have had a fantastic Christmas.)

Anyway for all my users, your present is now available for download …

I am quite happy that I have finally solved the graph jiggling problem. Although the changes required were huge, MacHg is definitely the better for it now. Actually, in general I am quite happy with MacHg 0.9.12, since I have managed to solve a number of tricky under the hood type problems in this release. Now I can get back to a few more UI sorts of issues and most importantly additions. (Full 0.9.12 release notes.)

MacHg 0.9.12 is almost a candidate for MacHg 1.0.0 but the refactor present in this release (0.9.12) is truly massive so some regression might have been accidentally introduced…

(The annotation view is the major feature planned for MacHg 1.1.0.)

Cheers, Jas

Well that was quick. An configuration error crept into the release of MacHg 0.9.10 and so I have released MacHg 0.9.11 to resolve this issue.

The issue was that if people had previously used MacHg then in their ~/Application Support/MacHg/ folder there was a hgrc file that MacHg had previously installed. But this file was missing the cedit extension declaration. Fresh MacHg installs didn’t have this problem. Also if your ~/.hgrc has the cedit extension then this problem also didn’t show up.

In any case MacHg 0.9.11 solves this configuration problem. Grab a copy of MacHg 0.9.11 from the usual downloads page.

Cheers,

Jason