With version 2, the primary focus was creating an integrated workbench for dealing with Mercurial. I have been using the pre-release version for several months, and am quite impressed. Everything starts and ends at the workbench screen. The flow of operations is well handled, and gives you options when something needs to be handled.

An example would be a merge. With the previous version, if you had outstanding local changes, the merge dialog would merely throw an error, and you’d have to close the dialog, and do whatever you wanted to do about the local changes.

In Tortoise 2.0, the dialog reports that you have outstanding local changes, and gives you several options. Lose changes, shelve (temporarily store) the changes, see the changes. The choices you would make.

Once you make a decision (all from the merge dialog), the dialog updates, and will allow you to continue.

For merging files, you now have the option to explicitly do manual resolving on all files, or allow Tortoise/HG to do the usual auto-resolve. If you choose manual, then there’s a new dialog that shows all the files that haven’t been resolved, and those that have. The common options are all there, and one can easily re-do a merge.

The list goes on and on as far as improvements, so review the release notes.

The only ‘problem’ with this release is there is a learning curve when starting to use it. Things are not in the same place as the old version, so it will take some time to get comfortable with the new look and operations, but I think it’s well worth the effort.

I think this will be a huge boon for HG.

TortoiseHG is available for Windows and Linux. There is also a port for OS/X, but I don’t know what state it’s currently in.

The less interesting from a user perspective is the switch from the PyGtk UI library to the PyQt library.

The more interesting one is the introduction of a workbench. The 1.8 and prior versions didn’t have one location for doing everything from. If you wanted to browse your history and changeset graph, you used the repository explorer. When it was time to commit, a new dialog opened (accessible by toolbar buttons), but it didn’t close afterward.

After some usage, it wouldn’t be surprising to see a number of windows open for various tasks.

The 1.9 release now has the workbench. The individual dialogs are still available, and the distinct functions still appear on the Explorer context menu, but I find myself always working in the workbench.

Multiple repositories can be open at once, shown via tabs. All the functions you want to do are easily accessible within the workbench.

When it’s time to do a merge, it’s much smarter. In the old version, if you had uncommitted changes, it would warn you, but provide no options.

The new version warns you, but from the dialog gives you all the options you could reasonably want. Discard current changes. Shelve changes. Force a merge on top of changes etc.

Another area that is drastically improved is around merge conflict handling. The previous version would do an auto-merge always, and only prompt you if there were conflicts not handled.

The new version allows you to disable/enable auto merge right in the merge dialog. If you select ‘manual’ merge, then it will let you know there are conflicts that need to be resolved. A new dialog is available, and from there, you see all the files that had conflicts, and then on a file by file basis, you can decide to do an auto merge, manual merge, take left or take right.

There are many additional workflow improvements in this release, and I’m confidently using it right now. The biggest thing to be aware of is it’s built against the latest Mercurial, so if you can’t run the latest Mercurial, I wouldn’t suggest trying it out.

I’ve even started doing some contributing by reporting issues, and suggesting enhancements. If I knew Python, I’d be attempting to contribute code as well, but…

The only thing is you have to get past the sense of ‘humour’ of the author, but the content is good.

A Mercurial Tutorial

The project I’m working on has gone with named branches for branches, and therefore one repository, rather than what seems to be the generally accepted approach of copying the repository, and then pulling changes from the old one.

The end result is basically the same, but without the ‘baggage’ of named branches. Personally, I prefer being able to see a branch with a name, and knowing what it’s associated with.

The other decision we’ve taken is to generally use rebase, rather than pulling others changes, merging them together, and then pushing. The only real reason is it keeps the number of changesets down (no merges everytime I have changes and someone else has already pushed), and also keeps the branch in the graph straighter/cleaner.

http://stackoverflow.com/questions/818571/how-to-setup-mercurial-and-hgwebdir-on-iis

Good starting point. Comments mention in order to push, have to create windows user, and add them to push list.

The latest will always be marked as unstable, as it’s still being worked on, but I’ve been using it the past month or so with no issues. Some features are hidden, or have been moved, but the pace of development is very good.

The nicest thing is the integration. Everything can be done from the workbench, and an action flows nicely through a set of dialogs, and ends up at the workbench.

Multiple repositories can also be opened.

An example of the nice touches. This morning, I did a fold. Up pops a dialog with the merged commit message, a list of the patches being folded, and a checkbox to control whether the patch files are kept afterwards. Modify the commit message and press finish. All in one step.

Another major addition is around the patch queue, and its functionality. In the past, if you wanted to move a file from one patch to another, it involved a few obscure, and potentially dangerous commands.

Now, there’s an integrated MQ manager. It allows for easy movement of files from one patch queue to another, but ALSO allows for movement of portions of a file from one changeset to another.

So, if you do a refactor, and then start on other work, but have it in one patch, you can now create 2 patches out of it. Personally, I like to commit refactors and actual new dev work separately, and with the new MQ utility, this is feasible.

Bottom line, if you’re using HG, checkout the new workbench.

As a result, they devoted a full time developer to creating a fork of MercurialEclipse. They announced the release of RC1 a few days ago, so I decided to install it.

Well, all I can say is ‘Wow!’. MercurialEclipse was ok, but in one release, Intland has taken it to very useable. They’re calling their version HGEclipse to differentiate from MercurialEclipse.

2 big highlights. They synchronize view is now very useful, as it shows uncommitted changes, incoming and outgoing changesets.

They’ve also fixed the history/compare view. Mercurial tracks file copies, but MercurialEclipse would create an error if you tried to compare a file version with the current name to one with the old name.

HGEclipse resolves it correctly, and shows the differences.

This bodes well for the Eclipse plugin for Mercurial, and I look forward to seeing what other things they enhance/fix.

After the 3rd one, I figured there must be a better way…. then I remembered the DataMine feature of TortoiseHG (which I imagine is using Mercurial’s grep command).

So, enter my search criteria, and a file search patter. Do a search and up pops a list of files, lines and changesets that contain that information, throughout the entire history.

Obviously, this could be slow with a really broad search, but generally, it’s quite quick. Definitely much faster than manually searching throough all the revisions of a file.