The next version of TortoiseHG has been officially released. This release is a major upgrade from the previous version.

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.

I’ve started using the next release version of TortoiseHg 1.9. Two major things are happening.

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…

A reasonable starting point for understanding the basic concepts behind a DVCS, and Mercurial in particular.

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.