# Tuesday, June 05, 2012

This is the fifth post in this series

For our purposes, small team development, the majority of the time will be spent developing right in default.  This is by far the simplest approach and for a small team is very doable with no major side-effects.  However, it’s not without it’s own downsides.  For that we’ll cover branching in a later article.

Let’s get started. 

Open a command prompt by selecting your project's root folder and while pressing the Shift key, right-click the mouse and select open command window here


In a team scenario where you are working on the same code base you will want to look at pulling and updating your local repo with their changes. In our case, this is the abnormal case. For us we will almost always be working on the code base by ourselves.  If your team is needing to be more collaborative then working in default will likely not fit your needs well.  You’ll want to look more into developing in branches like the stable & default workflow outlined by Steve Losh.

With that in mind we can always start with checking the status of our code base.

Type hg stat.

hg stat will return a list (if there is any) of files that have either been added, deleted or changed since your last commit.

If it returns nothing then the repository is up to date (locally).  This doesn't mean it's up to date with the Server (Bitbucket).  However, in our simple case the Server / Bitbucket is used as central backup and retrieval.  If your working on a new feature then running hg stat locally will be an indicator if you haven't committed in your latest changes locally.

Below is a sample session of a work in progress:


M - The file has been modified.

! - The file has been deleted.

? - The file is new.

Let's say we are done with these changes and we are ready to commit them.

Typing hg addremove would give us:

This marks all new files as added to the repository and marks removes/deletes files from the repository.

There are separate commands hg add & hg remove with options to add/remove only some files if desired.

However, the files have only been marked.  They haven't actually been committed yet.

Note that the first two files that reported M are not in the list.  That's because they don't need to be marked since they are already under source control.

Typing hg commit -m "commit message" would commit the changes to the repository.


You should get back a prompt without any messages.  Looks like everything committed. 

Typing hg stat (again) should report nothing.  Your local repository is up to date with your latest changes on this machine.

Next steps?

You could keep on developing or push your changes up to Bitbucket. I like to do this often.  Let’s update Bitbucket now.

Updating Bitbucket

First create a repository in Bitbucket for your project. 

Login to Bitbucket and create a repository.

Select your new repository from the Repositories drop down and copy the text after hg clone.  Since we are going to do this from the Tortoise Client instead of the command line we leave off the hg clone.

It should look something like https://username@bitbucket.org/username/repositoryname. 

We are using HTTPS to connect but you can also use SSH although I won’t be covering that here.  If your interested in using SSH instead, Atlassian has a great write up.

Right click your project’s root folder and select Synchronize, under the Tortoise Hg menu item.


Select the local item in the dropdown list below the icons and paste in the repository address.


Then select the push icon. 


You should be prompted for your password and possibly your username. 

Getting code from Bitbucket

To get code from Bitbucket, we’ll do the same process as a push except now when we are in the Sync screen, we’ll use the pull icon instead.



Recommended process

I like to commit early and often.  I try and break down the feature/bug I am working on into small chunks of logical work.  When I get a logical chunk done I commit the work.  If the feature or bug is small enough then I do it all in one commit. 

I like breaking it up because this allows me to more easily go back to an early version if something goes wrong. It's easier to go back, start over if you will, than try and undo the mess I got myself into.The larger the feature, the more I try and work in logical chunks.  For a large enough feature I also will use a branch.

I like to push my changes to Bitbucket often.  At least once a day and perhaps more.  On rare occasions I will not push my changes in a day.  Usually this is when I am hammering out an idea and the code is unstable still.  I try to live by “the code shouldn’t break the build” as a general rule of thumb for deciding if I should push it up.  If you are working in small enough chunks this should be a rare occurrence.

As a general guideline I push changes to Bitbucket when I have completed a feature/bug fix. However, this is not a hard and fast rule and I try hard to push my changes at least at the end of the day. 

When more than one developer is working on a codebase the general guideline is to push when you have completed and tested the feature along with everyone else's submitted work. In a team someone else could have pushed up a change.  You’ll need to bring their work down (hg pull and hg up or hg merge) and test it with your code to ensure your changes continue to work as well as your teammates.  If you need some more information on working in this kind of scenario please check out HgInit’s setting up for a team. SecretGeek also published a nice workflow sample based off of HgInit’s explanation.


The basic workflow of working on code on default is:

  1. hg stat
  2. hg addremove
  3. hg commit -m "Commit Message."
  4. hg stat

You can also run hg log to see what has been done lately.


Next, were going to go over deleting/reverting changes.

Posted 06.05.2012  #    Comments [0]  | 
# Thursday, May 24, 2012

At my current job and my last I either worked solo often on projects or in very small overlapping efforts of a few team members.  In both of these jobs the team used Visual SourceSafe (VSS) and it was working well enough but no longer supported. Jumping to TFS felt like overkill for a team on VSS and not affordable. 

MS has announced TFS Express which might go a long way in changing this. However, I have found the world of Distributed Version Control Systems (DVCS) with Git and Mercurial to be game changers.

As I have been learning more and more about DVCS I found a need to work up a new process that I can hand over to my team members or a new employee to help them get up to speed fast. Teams of larger size or even code bases of much larger complexity require sophisticated workflows. In my last two jobs I haven’t fallen into this category. 

This series reviews the process I have put together for a small team (1-5 members) with less complex code bases.  I’m not a Mercurial or Git expert by any stretch of the mind but I have found a flow that is working great. I welcome any thoughts and suggestions for improvement from the more seasoned DVCS pro’s.

Let’s get started.

1. Mercurial or Git?

2. Installing and basic configuration of Mercurial

3. Workflow basics

4. Setting up your repository

5. Working in default

6. Reverting/Deleting

7. Branching

8. Tagging & further reading

Posted 05.24.2012  #    Comments [0]  | 

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]  |