Partager via

DevDiv Source Control

  • Article

A question that I was recently asked on a trip was what source control system we use and what it looks like. I've spent quite a bit of time in this space for our team and will try to answer the question with this post.

What source control provider does your team use?
During the Visual Studio 2008 product cycle the primary tool for source control was an internal tool called Source Depot. While not all teams used Source Depot, yes some used TFS, it was the primary source control provider and it was what most of the internal tools were built against and we didn't have time to rebuild them to completely target TFS. Any important branch, Main, Beta1, Beta2, RTM  was in Source Depot. The move had started though... we are beginning to dogfood TFS and tools where getting ported.

Once 2008 was shipped the entire division focused on moving to TFS. This is now the only supported source control provider moving forward for new and future work. We will continue to support Source Depot for a while as our 2003, 2005 and 2008 source code lives there and we must continue to support those products.

What does your source control structure look like?
Generally our source code tree is about 3 levels deep. The top level root branch is referred to as Main, child branches of Main are referred to as Product Unit (PU) branches and child branches of PU branches are referred to as feature branches. Some teams have one PU branch and one feature branch. These teams generally just use the PU branch as a staging area when taking integrations up or down. Other teams will have multiple feature branches that will regularly integrate up to the PU when their work is complete. It's often interesting for individuals to see that each PU within the division functions as their own entity handling check-ins, integrations, builds and the number of branches differently. While most of the teams function in a similar fashion almost every team has some quirk in their process. My team as long as I have been a part of it follows the single feature branch and single PU branch model.

How many integration\merge conflicts do you normally have to deal with?
This really depends on how the branch structure is setup and how much your team needs to change shared code vs. team specific code. Generally I would say the number of conflicts my team sees on average is around 30 - 40. Though the other day when I was doing an integration of QA code only I had around 5,000 conflicts. Fortunately I didn't have to resolve each of these by hand, because the owner of the files just said they wanted to take what ever was in the destination branch and to ignore the incoming changes. This was a blessing.

Is your test code under source control and if so where do the sources live?
Yes all of our test code is under source control. It is treated very similar to the product code and is branched with the product code. While this was probably the answer that you expected the test code has not always lived with the product nor was it branched accordingly. This was a recent change in the last three years. I feel this was the correct change, though I still feel some in the division might not agree. When we added the test sources to the product source control I believe it almost double the size of the depot in size and tripled the number of files.

How long does it take to sync all of Main?
I don't have any data on this. I will work on getting some and make another post out of it in the future.

Comments