CODEWITHSUNDEEP
visual-studiotfs
Dean Kuga
Dean Kuga

Reputation: 12131

TFS structure for "base" and "derived" projects

I am looking for some ideas and suggestions on how to implement a class hierarchy type of structure of VS projects in TFS. Specifically, I want to have a "base" project which will contain all the common functionality the rest of the projects will inherit. When the changes are needed in the "base" project it should be relatively easy to propagate these changes to the rest of the projects which are based on this "base" project.

The obvious approach is to branch other projects from this "base" project and merge up the tree from this root project when there are changes but I've never tried that before and would like to hear from someone who attempted something like this before or has extensive enough experience with TFS to be able to point to inherent issues or pitfalls of such idea...

Upvotes: 0

Views: 120

Answers (1)

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51183

The projects in source control is actually folders. So your question is somehow the same as how to structure your folders in TFS.

Your base project is the some concept of main in branch which is root folder that acts as a container folder for your main source tree, together with accompanying project artifacts such as design documentation, scripts, and test cases. The Main folder also usually contains your Visual Studio Solution (.sln) files.

In TFS you could convert a folder to a branch.Then you just need to branch your base project to other projects. After have a branching relationship, you will be able to merge changes between the 2 branches. Besides you could also use branches to accomplish the following goals:

  • Manage concurrent work by multiple teams on the same codebase
  • Isolate risks that are introduced by different sets of changes to the codebase
  • Take snapshots and then support subsequent isolated changes (for example, to create a release branch)

Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.

When you perform branch operations, branches have important advantages over folders. Branches support version control features that provide extra visibility into your branch structure and into where your changesets have merged. (For more information, see these wonderful links: Visual Studio TFS Branching Guide)

For inherent issues or pitfalls of such idea, one thing is you might have to resolve conflicts when you get, check in, merge, or unshelve. Another thing is permission. It's better to avoid everyone have permission to merge changes from the “derived” projects back to the "base" project.

Besides you can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy. If you are interested, you could check this blog which shows how to configure that.

Upvotes: 1

Related Questions