Experience using TFS 2010: (Control system. Branches. Creation)

Very often I hear that Microsoft’s version control system is a quick crutch. I will try, if not to disprove it, then to show that this system copes with its tasks. And even if it is a crutch, it is very high quality, colorful, functional, easy and intuitive to use.

Introduction

To begin with, we had 5 years ago: We had, and still have, an excellent, in my opinion, IBM Rational ClearCase version control system, and there is also a change management system and IBM Rational ClearQuest task distribution in addition to it. . Until a certain point, while all development was conducted exclusively in C ++, that was enough. True, there was one small problem; the system was perfectly integrated into all development products, except Microsoft. I don’t know if this was due to a tacit war between IBM and Microsoft, but the system was extremely unstable with Visual Studio 2005, often incorrectly displayed the state of the files, Visual Studio was constantly falling when we turned on the functions we needed. In addition, a protocol was used to access the system, so in our company, access to the system could only be obtained by users who were in the company's domain, which did not automatically allow access to the system from a personal laptop. Of course, over time, almost all of these shortcomings were eliminated, but at that time it was exactly that.
This was the reason for the search for a new system, after not a long search, we decided to try TFS 2005. Actually on it, we can say, we learned to work, and we studied a new system for us. We worked on it for a long time, about 2 years and immediately decided to try TFS2010. I want to tell a little about this system, and I will begin with the most basic, in my opinion part - the version control system.

As I said, we worked all our life on ClearCase with the setting of UCM and used to do everything in accordance with the UCM process. One of the main actions in this process was Deliver operations (transferring changes from the developer) and Rebase (receiving changes). It looks on paper very simply, the developer makes changes in his branch, and when he finishes work, he throws them (in TFS terms, makes Merge) them into the integration branch, respectively, if the developer wants to receive the changes, he should do Rebase (again, make Merge in developer branch), see Figure 1.


Figure 1 - Deliver and Rebase operations

In fact, it looks a bit confusing, see Figure 2, but in any case, all this is not very difficult and, in the end, you even begin to think that it cannot be otherwise.

Figure 2 - Tree of operations in ClearCase
')
And so, we needed a tool that would allow us to work, following the exact same process. Let's try to do the same with TFS2010.

Creating branches

First you need to create branches. We need an integration branch, which will allow us to store only releases that go to users, a branch that we call a site for exchanging changes between developers, and the developer’s own branch, in which the developer does his tasks.
To do this, we will make a test project in TFS2010 and connect to it, see Figure 3.

Figure 3 - Connection to the test project

Now open the Source Control Explorer by clicking on the Source Control of the project in Team Explorer, see Figure 4 and add the Project-Integration folder to the project, this folder will be the base for us to store the Release code, in fact, it will be the branch of integration, after its creation and add version control, immediately convert it to a branch, see Figure 5 and Figure 6.

Figure 4 - Calling the Source Control Explorer


Figure 5 - Creating the integration branch


Figure 6 - Creating the integration branch

Now you need to create a site branch, which will be a place through which developers will exchange code. This branch should branch off from our newly created integration branch, see Figure 7, and we will create a branch from it, Figure 8.

Figure 7 - Tree branches


Figure 8 - Creating a site branch

And finally, we need to make a developer branch using the same algorithm, only we will be branching from the site branch. Let's make two branches for two developers, see Figure 9.

Figure 9 - Developer Branch

Now we have a beautiful tree structure that exactly matches the one we used in ClearCase UCM.
The view of such a tree structure of branches has nothing new, it is a common practice. It allows you to separate the temporary actions of developers from completed. The developer performs all his tasks in his branch, thereby not changing the main code that is on the site branch, and only after the work is completed, he throws a good, tested code into the site branch. Thus, we will always be sure that there is a working code in the site branch.
You can also create a branch from the developer branch if you are simultaneously working on several tasks, for example, fixing a bug and actually implementing a task, and merging changes into your developer branch, as necessary.

The site branch can also be used in remote development, that is, for example, one team is in the Urals, the other in Moscow, and each team implements some complete functionality in the project, developers in the Urals throw off their code in their site branches, Moscow team in his. After the teams have finished working on their functionality, and all the changes are in the site branches, they can merge everything into a single integration branch.

There is one subtlety when working with Russian developers - they are not distinguished by a special development culture, and can make changes to the code at any time, in any branch and at any whim. This often led to the fact that even such a strict branch structure did not protect against the non-working code in the site branch, therefore our next step would be to set up access rights to the branches and prohibit certain actions so that the code was always of high quality. But more about that next time ...

Useful links:
Team Development Using Visual Studio Team Foundation Server: Reference