This project is read-only.

For the development stream we should be using dev branch to keep the main tree and its history isolated and clean. This is necessary because in that case we can quickly act upon any critical issues and be able to patch the dev branch tree appropriately so main tree’s history would be clean and concise.

I am going to provide relevant examples as appropriate along with the screenshots to give you the idea what is all about.

I will be using a demo project to give you the sense of why some of the concepts I advocate for are important and useful.

So, lets get started…

I use the following folders structure to do my development:

C:\rd\WebsitePanel\dev - contains development stream (a.k.a dev branch)

I do prefer this structure because only by looking to the folder name I can quickly understand its purpose and intent, so do you. First of all you need to create corresponding folders and if you are looking for the shortcut here it is (PowerShell only):

New-Item –Path \rd\WebsitePanel –Force

Afterwards you navigate to WebsitePanel folder created above (assuming you have already installed TortoiseHg) and run the following command:

hg clone https://hg01.codeplex.com/websitepanel dev --updaterev dev

image

This clones the remote repo and when done also updates your working folder to switch to dev branch automatically (updaterev dev argument). Also you can easily verify which branch your working folder is hooked up with by running “hg branch” command in a target folder (see a sample screenshot below):

image

Now lets do some demo-driven development to see how things will work for different cases and what the flow is.

A Simple Case

I would consider a simple case to be defined as follows: no changes have been made since the last time you synced with the remote repo and done some work on your local copy.

For instance, I decided to take over a bug fix related to an invalid cast exception being thrown by Hyper-V For Private Cloud module (see #111 for further details). So, this is the workflow I used to use when fix issues in the code:

  1. I did my best to figure out a problem and the repro scenario;
  2. Then put some code to fix the issue;
  3. Did some testing around it on my demo environment to ensure I didn’t  do any harm to the existing code or break anything;
  4. Now it is time to commit the changes have been made to my local repository first (remember you always work with your local copy of the remote repo);

Before committing my changes I run check of the current status for the entire enlistment (-um argument allows me to see unknown and modified files):

image

If you are wondering why this is ever useful then here it is – this command will let you see any “unknown” files (these you have added while developing but forget to ‘tell’ the repo about) and the chances you miss to add new files are very low because this command (run in the root) will catch such issues on the spot.

So, lets begin committing the changes but this will take a few steps no just a single one:

First of all I should verify if there are any incoming changes from the repository:

hg incoming

image

Okay, nothing new has been added to the repo. Now it’s time to run the entire build and check that my changes are going to be built actually (please note the location at the time of issuing the command):

deploy-debug.bat

image

Once the build is successfully completed (eq. no errors) I am 100% sure my changes are not going to break the build as well, but let’s run hg status once again to see what we are about to commit:

hg status

image

As you can see some other files have been modified as well (this is done by the build process automatically and during the development process you do not need to submit these modifications). So lets revert these files:

hg revert WebsitePanel.Installer\Sources\WebsitePanel.Installer\App.config -C

hg revert WebsitePanel.Installer\Sources\WebsitePanel.Installer\Updater.exe –C

hg revert WebsitePanel\Sources\VersionInfo.cs –C

hg revert WebsitePanel\Sources\VersionInfo.vb –C

Now we are ready to commit the changes:

hg commit –m ‘#111: System.InvalidCastException is thrown when accessing a VPS via Remote Desktop Connection feature’

image

Note: You may wonder why I have not specified –u (--user argument) this is because I have set up this key in my root .hgrc file. This saves the amount of keystrokes I need to perform every time. More details on how to configure .hgrc file properly are coming and will be covered in a separate article.

Already…. We are done now with the local repo and now it is time to push the changes to the remote repo:

hg push

image

That should be it! Smile

 

PS. If you find an inconsistency or something is explained wrong, please feel free to step up and share your feedback via comments so we can fix it quickly. Thanks!

Last edited Jun 7, 2012 at 6:50 PM by ptsurbeleu, version 1