You can integrate JIRA and TortoiseHG Workbench at two levels:

• Only highlight the issue in your revision details and allow quickly open it in browser
• Connect to your JIRA and show the list of issues with all filters, view details and pick issues to include in your commit.

Now we’ll focus on the easiest option to implement – displaying issue number in commit message  and open it in browser.

Required settings:

• Open Issue Tracking category in Settings dialog of TortoiseHG
• Set properties to
• Issue Regex: \b\w{3,7}-\d+\b
• Issue Link: http://your.jira.server.com:8080/browse/{0}
• Ignore the rest of settings for now

See the screenshot, it should look like this:

Now if your commit message in revision details will contain a code of an Issue (or what will be detected as code) it will be highlighted as a hyperlink and clicking it will open a browser with your Issue details in JIRA.

I’m trying to get a deeper integration working, unsuccessfully so far. When it will be done will publish a follow-up post…

This feature is well enough to upgrade your TeamCity to latest 6.5. Of course, if you’re using a DVCS (Git or Mercurial) and use feature branches. As feature branches can be active for a longer time and last few dozens of commits, you want to plug that branch into your Continous Integration process. That’s for sure…

Feature description by JetBrains:

Remote run on changes in DVCSs branches: New build trigger added that watches for commits into Git or Mercurial branches and adds personal build to the build queue when commit detected.

It took me some time to find how it can be enabled. Finally found it in documentation. The trick is – it’s a build trigger. Just add a new trigger, called Branch Remote Run Trigger and enable it.

You can specify a pattern that will be used to select which branches will be picked up.  I’ve specified “*” because I wanted that every branch to be continuously built & tested.

But you you have really long-living branches I would suggest a separate build for it however…

If you’ve put (or want to put) your .gitconfig in your home directory (C:\Users\username\) and git cannot find it you may try to add a user variable called HOME and set it to %USERPROFILE%.

See screenshot for details:

Useful commands:

git config --global -l
git config --global –e

First will show your global configuration file, second will try open it to edit.

Disclaimer: I’ve wrote this guide for my teammates that started diving in Mercurial. They came with Subversion background and after looking how they are working with Mercurial I wanted to show them one of more flexible workflows. It’s not a definitive guide. Just one of the ways to manage multiple work items with Mercurial and TortoiseHg 2.0. Oh, and it’s illustrated…

The Story, a real one…

One of the devs was working on a feature and wanted to push it to remote repository. Feature, being incomplete/not finished/full of bugs makes using some parts of the app awkward. And/or it’s keeping out other devs working in same source code area. Or the developer wants just push it and go fix an annoying bug he just spotted in other area…

What to do?

First of all, don’t keep it local! You should not try keep your modifications local. Mostly because your PC is not as reliable as our servers and also work you do isn’t visible to other team members.

Let’s formulate the problem: have ability to manage few work items simultaneously.

When it’s useful?

• A piece of work (issue/ticket/feature/bug) you’re tackling currently can take multiple days to implement. Even weeks.
• Multiple work items are useful when you have to quickly fix a bug in ‘default’ line when keep working on another feature
• You can share your unfinished work or ask an advice/review on it from your teammates
• You want to do something experimental, a crazy idea to try and then throw it to recycle bin.

Solution?

One of the options is use Mercurial named branches. I’ll describe a small workflow (with pictures, so you don’t get bored) describing how you can manage multiple work items at the same time.

Here is the algorithm, to get you on the track. It’s command line log with commentaries:

hg branch ticket-17                        // creating branch ‘ticket-17’
(do some changes)
hg commit –m “my commit message”           // committing to the branch
(more work, more commits)
hg update default                          // switching to default line
hg merge ticket-17                         // merging branch ‘ticket-17’ to default line
hg commit                                  // committing your merge

And that’s all. I hope you’ve got the idea.

How to do it with Tortoise HG 2.0

Configuration

To be able to push your branches to remote repository you have to configure TortoiseHg to allow new branches.

The picture:

Steps:

1. Click Synchronize
2. Click Options
3. Check “Allow push of a new branch”

Create new named branch

The picture:

Steps:

• Select the working directory in log view
• Click on button with name of current branch – “Branch: default”
• Select Open a new named branch and give it a name. Short and clean. Or long but anyway clean & descriptive.

When you’ll press OK your current branch button will change to “New branch: feature-1”

Get the work done and commit to your new branch

No pictures here as working with code is a very intimate process.

Just be sure you’re committing to the right branch.

Update to default branch

Picture:

Steps:

1. Select the “head” of default branch (the green label with name of the branch). Or, if you want to get creative, another branch where you want to integrate the “feature-1”.
2. Click “Update…”

Merging changes from feature-1 to default

The picture:

Steps:

• Ensure your working directory is default branch.
• Click on the head of “feature-1” branch and choose “Merge with local…”

A Merge dialog will open.

• Review one more time the what you’re about to do
• Click Merge
• You’ll be asked to commit your merge. Change message if you want and do commit.

You’re done!

Well, almost… Now when you’ll push to remote repository the “feature-1” branch will be also pushed and everyone will have access to it. And your work backed up on the server.

– Easy!

ReSharper 5.1 will display two IntelliSense combo boxes when you’re editing your xaml. An extremely annoying, known and yet not fixed bug  reported 5 months ago…

…It’s a developer oriented productivity tool. Oh my…

AnkhSVN

A mate came on me with “I found a wonderful SVN client which works from Visual Studio. It’s called AnkhSVN“. When I tried it last time it was in version 1.x, ugly & buggy. Having a well working TortoiseSVN I had no regrets uninstalling it.

Lately it passed a major update. It looks nicer, integrates well in VS and has all functions required for day-by-day work with Subversion. The mate who recommended it said that he found no problems during a week of trying it.

Ok. Having a refactoring to do that will involve moving few files I decided to give it a try. Moving/renaming files is one of the pain points when working with TortoiseSVN. After committing my changes to repository, the TeamCity server failed to build the project – few files was missing or had unmodified content when it should. AnkhSVN didn’t committed all changed files to repository. In VS they was shown as unmodified, but TortoiseSVN show them as changed files. A commit from TortoiseSVN has fixed the problem.

Still in doubts about it, worth keeping or not…

MBUnit Plugin for Resharper

I wanted to run test suite of Rhino.Mocks which uses MBUnit. First try – installed last version of MBUnit plugin for Resharper. It worked nice when I run a single test fixture. But failed to find any tests when I choose “Run Unit Tests” from context menu of a project or solution. Uninstalled.

Gallio Automation platform

Still wanted to run the Rhino.Mocks’s unit tests, installed Gallio a bundle that contains among others the MBUnit, a standalone test runner and yet another MBUnit integration into Resharper’s Test Runner. Results:

• Integration with Resharper: didn’t discovered all test from test project, cannot run those discovered.
• Standalone test runner – cannot run test suite, FixtureExecutionException.

The last two tools concerns MBUnit. All I wanted to do is just to run quickly a test suite. I can do it from console, but it’s painful and I want to do it from VS and have results there. I can do it with TestDriven.NET – but I don’t like it because found it too intrusive in my work environment. I think this is the reason why we haven’t moved to MBUnit from NUnit. It’s it superior as unit test framework, but weak tooling support make it unusable for us.

& no time now to check what is not working and how to fix it. May be later…

PS: I’ve seen it one more time: It’s very important the very first impression about something to be positive. If somebody tries your software and it blows up or doesn’t do what is it about, you fail. But this is another story…

After installation on my Vista box, TortoiseSVN cannot start, giving an entry in event log that says:

Activation context generation failed for “C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe”. Dependent Assembly Microsoft.VC90.CRT,processorArchitecture=”x86″,publicKeyToken=”1fc8b3b9a1e18e3b”,type=”win32″,version=”9.0.30411.0″ could not be found.

At first sight, the missing “Microsoft.VC90″ points to absence of Visual C++ Redistributable Package. Installing all of his versions didn’t help. After trying to work out this error, it magically disappeared and TortoiseSVN started successfully and worked well…

…until today, when I’ve upgraded to 1.5.2. Same error. Didn’t want to start. Now on two PC’s from office.

After searching for solution, found on a TortoiseSVN’s discussion lists a recipe that worked OK for me. I’ll cite it here with explanation, is given by Stefan Küng, one of TortoiseSVN developers:

try this:
uninstall TSVN, reboot, install it again.

There’s a problem with the new CRT merge module from MS: it does not recognize always that is has to update itself.

The good old way: uninstall, reboot, install. So windows95-ish.