Branch in Team Foundation Server

Branches on a source control is very hard to maintain. I hope most of you will agree to it. I am not a guru in it either. We had a release based branching in our previous project.

Problem statement: When we had same code file to be changed and are in different branches for 2 different releases and releases separated by a duration of 15 days. Release A will go prior to Release B. Also there is a Trunk from which all the released needs to be pushed to production. There could be few of below mentioned problems:

  1. Release A will be postpone and Release B needs to be pushed to production.
  2. Release A went to production and needs to be rolled back.
  3. Both Release A and B needs to be released at once and later it was decided that Release B will be postpone.

The list may not stop here but I hope you got the idea. For any release it has to merge with trunk. The solution we followed was people dependent. So any of the changes that was required will be done by the team.

So for example in problem 1:

  1. Release team A will get latest from trunk.
  2. Comment out or delete all the code that was a part of release.
  3. Check in clean release to the trunk.
  4. Release team B will get latest from trunk.
  5. Push new release to production.

No marks for guessing the plan failed. There were lots of wrong deployments, clashes and frustration.

Possible Solution: Personally I feel there was no need of branches for smaller release. It could had been managed by better version numbers and labeling on single branch. The design team or 2 teams for release needs to take care of how can they create separate files for different functionality. A feature in Dot Net called as partial class could be used too.Thus managing the release purely on files. Thus avoiding the conflicts totally. Thus build will contain only files from the specific releases.

Exceptions: There could be some exceptions, for instance few web service class cannot be separated or few God classes in legacy code cannot be re-factored. Also if we have totally new big module of 6-8 months long that could be on a separate branch.

Json Data between UI and handler continued…

I hope you have read the initial part of this post here.
5. Lesson i have learned the hard way is, If we are dealing with complex objects a mix of array and complex object. Make sure the property name of the javascript class and .Net class is exactly same.
For instance if the JavaScript content is
function jsonmenuwrapper(menu) { = menu;

function jsonmenu(id,value,popup) { = id;
    this.value = value;
    this.popup = popup;

function jsonpopup(menuitem) {
    this.menuitem = menuitem;

function jsonmenuitem(value,onclick) {
    this.value = value;
    this.onclick = onclick;
var myjsonmenuitem = [];
    = new jsonmenuitem("value","onclickMain");
    = new jsonmenuitem("value1","onclickSub");
var myjsonpopup
    = new jsonpopup(myjsonmenuitem);

var myjsonmenu
    = new jsonmenu("1", "Reports", myjsonpopup);
var myjsonmenuwrapper
    = new jsonmenuwrapper(myjsonmenu);
The C# class must have class like
public class JsonPopup
    public Menuitem menuitem {get; set;}

function jsonpopup(menuitem) {
    this.menuitem = menuitem;
The property name in the class must be same in both JavaScript and C#.