RiskFactor

Now that I have been working with TFS for a while I’ve done some experimenting with my Branching Strategy after much consultation with the Branching Guides that are available on CodePlex (TFS Branching Guide 2.0, TFS Branching Guide 2010). These guides have a wealth of information that should most definitely be consulted when you are considering your own Branching Strategy.

One of the keys to a successful branching strategy is to branch when necessary and only when necessary; no more, no less.  That being said, there are still a number of valid ways to branch from the most basic to the more complex.  Here are three diagrams from the TFS Branching Guide that show the three most common branching strategies.

Basic

Standard

Advanced

As with all guidance, there are exceptions.  In my case I was looking at the Standard branching strategy and finding myself in a situation where there were times when I needed to perform several Hotfixes over a course of time.  However, with at least one of my products there was no way to determine how many Hotfixes we were going to have before the next major release.  Following the Standard or even Advanced strategy didn’t allow me to dynamically add Hotfix releases as an issue was resolved and ready for RTM.  So, I came up with the idea of branching from MAIN to a Baseline Production branch from which all my other RTM branches would originate.  This allows me to create a new Hotfix branch as needed from a common Production branch.

The diagram for my Branching Strategy ends up looking like this:

This strategy falls somewhere between the Standard and Advanced strategies defined in the Guidance but also incorporates the flexibility to branch for Hotfixes when needed.  It also allows for concurrent development on a Service Pack should that be needed while still having the Baseline Production branch that acts as an accumulation point for all changes on Production code.

I am sure I am not the first one to come up with this particular strategy since “there is nothing new under the sun.” So, I would love to hear what you all think about this particular strategy.  What do you like about it? What do you see as some of the issues with it?

Tags: team foundation server, tfs, branching strategy

My team at work has finally gotten to a good point for migrating our source code for several of our products into Team Foundation Server.  I have been using the Workgroup edition of TFS at home for over a year now and really enjoy the features of both the source control as well as the project portals.  In fact, I haven’t had a single issue with TFS at home which is why when I ran into a puzzling issue with my project portals at work I really got thrown for a loop.  With my new portals I was experiencing an issue on both of my development machines that was preventing various action menus from being displayed on the home page as well as in my document libraries and on other pages.

For instance, if I was in a document library and tried to open the drop down menu for a given document I would get a Javascript error of Object expected generated in the script from the ~/_layouts/1033/ows.js file.  Here’s a screenshot of what I was getting:

So, after spending two days reviewing permissions in TFS, verifying that IE was up to date, working with our local SharePoint expert, and searching on Bing and Google till my eyes bled, I had just about given up.  Then this afternoon I found what I was looking for here. Come to find out my whole issue was the my User Agent string being generated by IE was too long for the TFS WSS instance to handle properly which resulted in the thoroughly baffling behavior I was seeing on my portals.  Since I have every version of the .NET Framework on my machine, plus a slew of other add-ins and applications my UA string was well over 200 characters.  So, to resolve it I made a few edits in the registry to eliminate the nonessential keys being used in IE to generate my bloated UA string.

If you are having these same issues, you can check your UA string length here. And if you need to shorten it, you can find a quick guide for the registry keys to pin point here.

Tags: sharepoint, tfs, team foundation server