VSTS2010 CTP11: Source Control – Branching management – Part 2

Hi all, I’m still going through the Branch system of the Source Control. We saw in the previous post that the branch feature evolved from the previous versions.
There’s a new restriction where you can’t create a branch that is inside its parent branch. I used to consider that case as a valid one, well, not a bad practice at least.

The next test I did was creating many branches to simulate a Main branch and many version of the product. The branching model used was intentional, I know it was not the best way to go in previous version, so I wanted to see if there was some improvement out there.

There’s a new good feature now to visualize the relationship between branches, select the branch, right-click on it, and choose the View Hierarchy menu item.


And you now have what you’ve expected for so long! 🙂


A graphical representation of your branches!

As you can see on the previous picture, we have many branches, all deriving from Main, the Version_1_5 is itself derived from Version_1_0.
The purple color is the branch from which you created the graph. And the cyan one is the currently selected one.

By right clicking from the Version_2_0 branch you have all the possible actions “branch-wise”.

For instance, the Merge… operation will propose you to merge from the 2.0 version back to the main one.

There’s a case I was particularly interested: merging two branches not directly related. In this case it would be merging Main and Version_1_5. This was not supported in previous versions of Team System, and I always thought it was a great miss. So here we go, let’s try it for now:


Oops, looks like it’s still the same as before. The only choice I have is to merge back to the version 1.0, which is the direct parent branch.
I guess I have to ask MSFT people if it will stay the same in the final release… Thread on the Rosario forum.

Ok now let’s try some merge. I have made some modification on the version 1.5 and 2.0 of the application. What I’m going to do is merge the changes from 1.5 to 2.0.
In the current state, I have two choices:

1) Baseless merge, which is not really a merge, as I would have to take care of everything manually.

2) Merging 1.5 back to 1.0, then to Main then to 2.0.

Let’s take the second case, it’s more interesting.

First it’s a good opportunity to test a feature I really missed in previous versions: being able to accumulate merges and check everything in just once.

Using the WICreator, I use Work Items to drive the merges, then the purpose of the program is to take all the changesets referenced by a given Work Item that are candidates to the merge (i.e. they are from the source branch and they were not already merged to the destination one) and merge them to the destination branch.
What I would have liked to do is multiple “cherry pick” merging operations, and then create only one resulting changeset (aggregate all the changes into one changeset is always better, don’t you think?) by check-in them all at once.
Unfortunately, we can’t merge to a file that is in pending changes with the current versions of Team System, leaving me no other choice that perform cyclic merge/check-in operations.

So to test this new feature, I have two changesets having a file in common that I want to merge from the 1.5 version back to 1.0.

clip_image002 clip_image002[4]

Let’s use the Merge operation:



Note above that both changesets are selected.

And the result is?

Yey, it worked!

After playing a little more, I realized that you can merge to a file that is in pending changes of type “editing” or “encoding”. This is understandable, except if you want to make what I just did in two separated steps: you can’t!
Because the result of the first merge will put the “Form1.Designer.cs” file in “merge” and “editing” pending changes, disallowing the second merge operation.

But, I’m very happy about the new feature, I really think it’s a good one!

Ok, so now let’s merge from the 1.0 to Main, then Main to 2.0.

From 1.0 to main, I had no issue, everything auto-merged perfectly.
From main to 2.0, I expected a conflict because the 2.0 had its own changes, and I wasn’t disappointed:

Here comes the new “Conflicts” pane in the Pending Changes window. I’m sure you know how it’s working with current versions, and I’m sure you don’t like it much.
As you can see, now the information becomes a lot more clearer, “theirs” and “yours” are long gone (at last) and all the information about conflict is summarized in one window, helping you to make the right call.
In this case we have two conflicting files: “Form1.cs” and “Form1.Designer.cs”. The current file to resolve is “Form1.cs”, you have now the three possible choices clearly displayed, waiting you to make the call.
Each conflict can be resolved separately or you can apply a given operation to a multiple selection, watch this:


I will manually merge these, and check the result in smoothly.

To summarize the merging improve in many ways, meeting most of the expectations.
Only the merge of indirectly related branches doesn’t seem to be supported, that’s still a great miss.

But thumbs up for the improvements !

Leave a Reply