This is something I can never remember.  This helps with the runtime assembly load process, but the compiler has a few more devices for location an assembly. Notably the reference path and the hint path from the project file.

I know I shouldn’t be picking up another book while there are still several on my reading list, one I’m still half way through, and branching into a completely new arena at work. The upgrades to the MBP made me consider why I do all my development through the virtual machine and don’t do anything natively. This doesn’t count the time I’ve spent tooling around with another language. Yet another book started, but never finished.

I have no ambitions on reading this right away, but hope to get to it soon, if only in a diminished capacity. There is still the matter of finishing the last book I started.

While at the bookstore looking for something that might help with the new arena, I noticed a book that I couldn’t help but picking up and laugh. Behind it was this book, the only OS X programming book in the whole store. It must have been placed there as joke. 

I’ve stalled with providing tips for a while. My development at work will pickup and I will soon lots of new tips. As we work into using C# 3.0 I am sure ReSharper will continue to impress. For today though, we have a simple reminder.

Alt+Page Up|Page Down goes to the next ReSharper gutter item.

This just saved me a ton of time. We are currently converting some .Net 2.0 code to target .Net 3.5. In so doing I am going to make use of the new language features. Our domain objects are classes with series of classic properties.

    private string fooberry;
    public string Fooberry{
        get{ return fooberry; }
        set { fooberry = value; }
    }

To convert these to automatic properties I could have copy and pasted {get;set;} after each property name and deleted the rest, but R# made it much easier. Alt+Page Down took me to the next suggest which was to convert to automatic properties. Alt + Enter opened the context window with the first action being convert to auto property. Pressing Enter one last time had it fixed.

    public string Fooberry{ get;set;  }

What made it so effective was I was able to hold down Alt the entire time and press Page Down, Enter, Enter, Page Down, Enter, Enter,etc. until my properties in that file were all changed. Total time to convert 20 properties…10 seconds. Try that with copy and paste. I bet it is a bit higher.

I’ve just impulsively upgraded my Mac Book Pro. When I bought it I opted to fore go the 200GB 7200rpm hard drive upgrade for the satisfaction of walking out of the store with it that very day. I knew any hesitation may result in financially responsible reconsideration. Good thing I didn’t! I’ve been really happy with the MBP, and dream of replacing my commodity desktop with a Mac Pro, but the same financial responsibility buzz kill prevents it.

Anyway,  after a brief fight with insomnia last night I decided to upgrade the MBP. I’ve ordered the following:

• 320GB 7200rpm hard disk – $110
• 4GB (2×2GB) DDR2 PC5300 Ram – $75

Grand total with free shipping from NewEgg was only $185. Much cheaper than a Mac Pro. The huge hard disk should allow from my XP partition and hopefully an a Ubuntu partition while not feeling cramped in OS X.

My only regret with the MBP is that it doesn’t have a nice dock. I suppose a USB port replicator would work well enough, but it seems like such an unsatisfying solution.

I’m changed my theme to something a little minimalist. Sorry if everyone liked having a choice of their background, but there were a few things I liked about this theme more than the previous one. I also switched to a white background for the text. I was hesitant to do so because I really like the dark code examples that match my color scheme. Hope everyone likes it. There is still some tweaking to do.

Just a quick reminder, most keyboard short-cuts work in other files types besides source code. In XML and HTML you can:

• Ctrl + Shift + / to toggle comments
• Ctrl + w to expand selection
• Ctrl + Alt + Shift + Up|Down to move elements up or down.

With a understanding of the basic concept of branching, we can cover the branching strategies my team uses and the level of success we’ve been able to achieve with each.

Never Branch

Honestly, most of our applications do not branch at all. Most of the applications our team maintains have were developed in Visual Basic 6 and stored in Visual Source Safe repositories a decade ago. We do very little maintenance development on them and no new development. We receive a bug, patch and deploy one or two bugs at a time so there is little need for extra overhead created by branching.

Branch for Maintenance

While we have no applications that follow this method, I feel compelled to mention the simplest method of creating isolation via branching. While continuing development down a single path, as we do with our VB6 application, a large development effort maybe underway and the need to patch the existing version arises. In this case we could create a branch from the label of the previous release, patch, release and merge the patch back to the main path. This was the method of branching mentioned in the previous post.

It is commonly called “Branch for Maintenance” because you branch at the time you need to apply maintenance to and existing piece of software. The reasons we don’t use this method on our team will be highlighted.

Branch for Version

On my current project we have our main source tree or “trunk“; however, we don’t develop against it. Our project has a predictable release schedule with a known set of bugs and enhancements that are to be included in each of these releases. We create a branch for each version we plan to release and commit all changes to that branch. This includes branching for any service pack version(s) we plan on releasing.

The branch allows us to concurrently work on multiple future versions and service packs. This is very valuable during the end of iteration when the app can spend several days, or even weeks, in user acceptance testing. During this time, while the app under user acceptance testing is frozen for new development, the next release can be under heavy development in its own branch. If issues during user acceptance need to be resolved, those patches can be applied to the tip of that version’s branch, and the next version is unaffected until the merge occurs.

We’ve found that as the date to branch the next version approaches, it pays to start merging back to the trunk. This will let the future branch start closer to its previous version. The closer the versions are at the start the fewer merges happen once the final merge is completed.

Some bugs cannot wait for the next release schedule. These bugs get their own service pack release and their own branch. Instead of being branched form the trunk, which may contain changes from other versions, the branch is created from the tip of the released version’s branch. This ensures that the start of the service pack branch is the exact source that is running in production. Once the patch is created, committed and released, we merge those changes back to the trunk and back down to any branches for future versions that might need the bug fix as well.

In addition to working from the branch, we create a build for each branch that will deploy the tip of the branch to the our development and testing environments. This is valuable in that the version in each environment can be switched with ease. We run the build for the version we need, it builds it from its branch and moves it to the correct servers. We can also take our servers back to previous versions if we want to recreate a production bug in a more transparent environment.

The benefits of this branching strategy outweighs the overhead created by the resulting merges. In most cases our merges are very straight foreword.

Branch for Feature

The last strategy we’ve only discussed using on our team, and actually haven’t implemented yet. Before we get into the actual method, an overview of the situation’s issues may help clarify our intended benefits.

One of our applications has several features and bugs being worked on at the same time by several people. In order to get the features and bug fixes to the users as quickly as possible the release schedule depends heavily on when the bugs can be fixed first. Once a high priority feature is completed, the app needs to go production. This means other feature and/or bug fixes may, or may not get included in the next release. Also, on some occasions a production issue comes in and needs to be fixed right away, before anything else goes to production.

As you can imagine, this is a nightmare to keep straight. There were two options for keeping unwanted code from making its way to production. Just as without branching, we could open up the code and comment out the code that can’t go, and then immediately uncomment it once the application releases. What we found was people were afraid to commit any changes to source control until their feature or bug fix was complete to avoid that nightmare. It could take a couple weeks to complete their feature and this means a couple weeks between commits of the code. Again, not something we desire. We want to integrate the changes sooner than a couple weeks.

What we are trying now is to create branches for each of the features/patches under development. Once they are complete we merge the branch back to the trunk. We then build and release from the trunk. This method allows us to pick which features that will be included in the next version. It lets us maintain history as the features develop since commits to the feature’s branch are isolated from other features.

This method is only valuable because of the unpredictable schedule and chaotic combination of features included in each release. It does create more overhead than branch for version since there can potentially be numerous branches all being developed concurrently. This means more merges and potentially more conflicts.

Branch Housekeeping

Source Structure

We struggled with where to store all these branches. We’ve settled on storing them closer to the trunks than we did initially. Here is an example of what our source tree currently looks like:

/MyApp/main/docs
           /libs
           /release.scripts
           /source/core
                  /core.unitTest
                  /domain
                  /domain.unitTests
                  /...etc
           /...etc
      /1.0/docs
          /libs
          /...etc
      /1.1/docs
          /libs
          /...etc
      /2.0/docs
          /libs
          /...etc

The directory libs is a directory to store our third party and external libraries used by the application. This directory is branched along with the source. This allows for different releases to use different versions of the same dependencies. The ultimate goal is to have everything needed to build the application under the main or branch directory. This includes all documentation and all scripts needed to setup the database. If we were really cool we would be able to have the build scripts setup the database based on the scripts in its branch, but we’re not that cool.

Building the Branch

To build each branch in the Branch for Version we create a build that we can instigate either by check in or manually. Be careful; if the build actually deploys to the build servers, only one build should be instigated by a check in. You wouldn’t want the version on the server changing depending on what was the last branch to get a commit. That’s not to say the build can’t happen to validate the tests still pass, but just don’t deploy to the server.

In our build tool you would see builds like:

• MyApp – 1.0
• MyApp – 1.1
• MyApp – 2.0

It works really well. With a button click we can put the next version on the development servers to illicit feedback on features in development and turn around and replace it with the version under user acceptance testing.

A friend at work asked me to describe the branching strategies we use on our team. Our organization is moving to Team Foundation Server from Visual Source Safe and people are starting to have a lot more confidence in branching their code. First, I wanted to go over the basics of branching and why working without isolation can, and have, caused so many headaches.

The most basic utilization of source control is to commit your changes and, hopefully, label the project for each release to your customers. You gain both the history of how the source has changed overtime and configuration information about how the source looked at the time of each release.

For applications with no new development, only service packs or maintenance releases, this works fine. There is little need to have concurrent development and therefore isolation of that development. Where this method becomes problematic is when deep into new development of the next version, you need to fix a bug in the version(s) you’ve already released.

If you don’t have the labels you’ll have a tough time resurrecting the source that was built in the previous release(s). Assuming you can identify the source in the previous build, you have a few options on how to apply the patch. If you are patching the most recent version you could comment out all the new features that aren’t ready to go to production, apply the patch to the main source, label and release the service pack. Then you would uncomment out the code and keep going on new development. This could be a large amount of tedious work. If the deltas that need to roll back are small this might not be a bad option, but in most cases it is just a headache.

The next simplest alternative is to rollback the source the to release label, copy the entire source tree, patch, label, and release. This does provide the isolation we desire and allows new development to continue without impact from the service pack, but now you are presented with a new challenge. You must get the changes from the service pack back to the main source. This will be very manual process where you will look at the files in each source tree, determine which has been changed, and apply the deltas to the main source tree. Not as bad as the other method, but it would be nice if we could maintain that relationship and get some help with bringing our changes back to the main source.

Enter branching. Branching appears to do exactly what we did when we copied the source. It does some fancy magic under the covers, but we can ignore that for now. It will create an isolated “branch” of the source that we can commit changes to free of worries of introducing new development to the service pack, or service pack code to the new development until it is complete.

Branches maintain that logical relationship which provide a huge advantage when it comes time to merge our changes back. At the time of the merge our tools can look at the histories of both the source and target branch and determine if code is being added, removed or changed. It will thusly apply the changes, but in some cases changes will exist to the same part of code in both places. This needs to be resolved manually.

While the merge is usually very smart, especially if the branch hasn’t diverted very far from the source, this doesn’t mean the source is free from errors. It is possible for one class to change in the branch and the other to change in the trunk and when merged back, no conflicting changes are found, but the classes don’t cooperate like that should.

The merge is more than a one way operation. In addition to merging from the branch back to the source of the branch, changes can be merge to the branch. This is useful if a bug fix was already patched in the new development branch and needs to be included in a service pack release.

That covers the very basics of branching and merging. I’ll be back in a bit to explain the strategies our team implements.

After the disappointing ending to my previous post, I now have much success to report. Once we had the correct path to the MSTest.exe on the build server, I was able to publish the results of my NUnit tests. There are a few things to note.

1. You still need MSTest.exe on the build server. I guess that is OK since we, at our organization, want to allow for the ability to run MSTests as well. I’m not 100% sure that happens on the build server or the TFS server.
2. As of now, if the NUnit tests fail, it will not run the MSTest. This is because we are executing the NUnit tests in the AfterCompile target as suggested in the NUnit for Team Build example. I’m not really sure why you would do both in the same solution, but if you do, you won’t see failures from both. Only one at a time. I’m looking into getting both to run, but that isn’t going to be much of a priority since we won’t need to run both in the same solution.

I am really excited that we have this running with such little effort. Thanks has to go to the NUnit for Team Build guys.

One to step two when time allows.

While working in an MSBuild file I notice ReSharper will help you out with using new tasks. If you use one it doesn’t know, it’ll offer to add its UsingTask statement to reference it.

It’ll throw this in at the top of the document.

<UsingTask TaskName="Fooberry" AssemblyName=""/>>