# Thursday, May 24, 2012

This is the fourth stop in this series.

I’m first going to mention using the command line and Nuget Package Restore.

To command line or not.  That is the question...

First time users, especially Windows heavy users such as myself have likely used Tortoise* at some point in our development to interact with a repository.  I started with TortoiseHg to help get the basics down but after Rob's challenge I gave the command line a shot and discovered two things.

  1. I was faster
  2. I understood Mercurial much better and what Tortoise was doing for me.

I still use Tortoise for a few things but for the most part I use the command line now for most operations. If you think this is the way for you have a look at posh-hg to add even more productivity.

Nuget Package Restore

Feel free to move on to the next section if your not using .Net.

Dependencies are something we must deal with in our version control story.  Nuget eases a developer’s life for managing dependencies but with Nuget Package Restore we can more cleanly keep our dependencies out of the source control but have an automated way of getting them into your project. 

Without Package Restore we would have to put the dependent libraries (dll's) in source control.  Usually one would create a library folder and have everything in this folder source controlled. 

With Package Restore we source control the configuration settings of the dependent libraries we are using with Nuget.  When we pull down a repository for the first time and build it Nuget will read the configuration and download all of the libraries in use.  We get a source control environment with the knowledge of what libraries we need but we don’t have to store the libraries in the source tree. 

To use it we’ll need to tell Mercurial to ignore the packages folder. The last item in the hgignore file in the third post has this covered. 

If you don’t like this idea, no problem.  You don’t have to use it.

Setting up a repository on your local machine

I do this with Tortoise although you can use the hg init command at the command line.

To use Nuget Package restore follow the instructions from David Ebbo’s post.

With TortoiseHg installed right-click on the root project folder.

Select TortoiseHg, Create Repository Here.


Keep the defaults and press Create.


Overwrite the hgignore file.

Either copy an hgignore file from another existing project in another folder OR copy over the text in the hgignore file with the text in the Ingore file section above.

Commit your project's initial state.

I do this with TortoiseHg as well.

Right-Click your root folder and Select HG Commit.


1. Check of the Check box in the upper left hand corner.  This tells Mercurial to add everything in the list.

2. Add a commit message.

3. Press Commit.


When prompted to add select add


Adding Nuget.exe (http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html)

Since we are using Nuget Package Restore we have to add the Nuget.exe to the repository.  Normally we don't want to save Dll's and/or Exe's to the repository.  The ignore file specifies this as the default.  As such we have to add it manually.  The same is true if down the line you need to use a 3rd party library that isn't available on NuGet.  In this case I would create a lib folder in the root of the project and place my library files in this folder.  From this folder I would add it to the repository and add a reference in VS.

Go to the .nuget folder in the root of your project directory.

Right-click nuget.exe, select TortoiseHg, Add Files... 

Keep the defaults and press Add


Notice the Icon changed to a plus sign for the file.

Select the Nuget.Exe file again and select Hg Commit


Add a comment and commit.


Your project is ready to go.

The next in the series will go into the commands for working in default.

Posted 05.24.2012  #    Comments [0]  | 

This is the third installment in Getting started with Mercurial for a small team

In this post we’re going to cover Workflow basics.

Mercurial / Team Workflow Practice

In a small team often the workflow process is not something that has to be complex.  There are a few different workflow techniques that make sense in this case.  Even in a 1 person team branching and tagging may seem unnecessary butthey can come in handy. 

First, here are a few great articles on workflow practices.



Steve Losh’s guides are priceless and serve as the basis for the workflow process described below.

Branch as needed (Read Steve’s description and come on back.)

The name may seem a little deceiving but essentially the recommended approach is to not worry about branches in general.  Development on the main line / default branch should work a lot of the time for a small team. Often when you are working in small team’s you don’t have to worry about features others are working on since you are likely the only one.  In the small cases as well where a few are working it is often in a way that they can develop features that are completely part of a different area of the code than you are working on.  You often don’t have to worry about updating the code base for a "hotfix" either which if you were developing off the default branch could present a problem should this be needed.

The reality is even in a small team you will want to think about these possibilities and plan for them if they will be an issue.  Hence, "Branch as needed".  If you don’t need it, then don’t worry about it.

When you do need to branch there are several techniques described at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/.

Branch with Named Branches

Even for small teams or code bases, branches offer some great advantages and should be considered a part of your process.  Branches offer a way for you to create a separate isolated area for you to develop a feature or bug fix.  This isolation allows us to fully develop the feature or bug fix without touching the default line. 

This gives us the flexibility to get rid of the branch if we decide it’s not working or work a fix in on the default line while we are still developing the feature on it’s own.  If we were not using a branch and a serious bug is found the feature code may stop you from being able to issue a fix for it until you’ve completed the feature.

I tend to use branches for features that I deem larger than a week to work on or if I am really unsure of how I want to accomplish it that way I can get rid of my work easily if I decide to scrap it and start over.

There are several ways to create branches in Mercurial.  Were going to use the Branching with Named Branches process. Branching with clones is also a great option if you are really unsure of your work and think you might need to trash it.  This is the simplest for trashing but requires a bit more work if you like it and want to merge it back into the original codebase.

Another very good approach is to use a stable branch for releases and have default be where you mainly develop. http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/.  Depending on your need for your product line this option may be a great option as well.

Next up, setting up your repository.

Posted 05.24.2012  #    Comments [2]  | 

This is the second post in the Getting Started with Mercurial for a small team.

This post is going to cover Installing and basic configuration to get started using Mercurial on Windows.

Installing Mercurial on Windows

I've installed Mercurial two ways and have found both very easy to use.

With TortoiseHg (all in one download)
Using Chocolatey (package manager for your applications on the PC, think NuGet for your PC apps!)

Mercurial Settings

There's several settings you can set per repo and/or globally on the machine.  The first of these to set is your username.

To set this at the computer level on a windows machine, find the mercurial.ini file in the Windows System UserProfile folder.

Add the following:

username = Your Name <your_email_address>

You can also set it per the project by editing the hrgc file in the .hg directory for your repository.

Ignore File

The ignore file (.hgignore) tells Mercurial what files to not source control by default.  You can add anything manually in the list yourself but Mercurial won't automatically look for the patterns in this file.  There are several examples out there.  Below is the sample I am using at the moment and have found it to work well.

# Ignore file for Visual Studio 2010
# use glob syntax
syntax: glob
# Ignore Visual Studio 2010 files
packages #be sure to manually add nuget.exe in the .nuget folder

The two resharper entries aren’t needed if you don’t have Resharper. The last entry we’ll explain in a later section.
Mercurial Basics

There are a lot of great resources on the internet for this.  Here's a recommended list that I found invaluable in getting me started.


http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html (the whole book is good)


http://tekpub.com/view/dotnet-oss/7 (Free video on Mercurial with CodePlex)

Command cheatsheets




Bitbucket Basics

Bitbucket also has a nice tutorial of their product at http://confluence.atlassian.com/display/BITBUCKET/bitbucket+101.

Play around, run through the samples in the resources above.  Getting the absolute basics down will help you for the next in the series, Workflow Basics.

Happy Coding! Smile

Posted 05.24.2012  #    Comments [0]  |