我正在寻找关于如何在TFS中实现VS项目的类层次结构类型的一些想法和建议。 具体来说，我希望有一个“基础”项目，它将包含其余项目将继承的所有常用功能。 当“基础”项目中需要进行更改时，将这些更改传播到基于此“基础”项目的其他项目应该相对容易。
显而易见的方法是从这个“基础”项目中分支其他项目，并在发生变化时合并来自此根项目的树，但我以前从未尝试过这样做，并希望听到之前曾尝试过类似事情的人足够广泛的TFS经验，能够指出这种想法的固有问题或陷阱......
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...
最满意答案
源代码管理中的项目实际上是文件夹。 因此，您的问题与如何在TFS中构建文件夹的方式相同。
您的基础项目是main in branch的一些概念，它是作为主源树的容器文件夹的根文件夹，以及随附的项目工件，如设计文档，脚本和测试用例。 Main文件夹通常还包含Visual Studio解决方案（.sln）文件。
在TFS中，您可以将文件夹转换为分支 。然后您只需将基础项目分支到其他项目。 拥有分支关系后，您将能够合并两个分支之间的更改。 此外，您还可以使用分支来实现以下目标：
管理同一代码库上的多个团队的并发工作 隔离由代码库的不同更改集引入的风险 拍摄快照，然后支持后续的隔离更改（例如，创建发布分支）
虽然您仍然可以在文件夹之间进行分支和合并， 但您团队的最佳实践是仅在分支之间进行分支和合并。
执行分支操作时 ，分支比文件夹具有重要优势。 分支支持版本控制功能，可以提供对分支结构以及变更集合并位置的额外可见性。 （有关更多信息，请参阅以下精彩链接： Visual Studio TFS分支指南 ）
对于这种想法的固有问题或陷阱，有一点是你可能必须在获得，签入，合并或取消搁置时解决冲突 。 另一件事是许可。 最好避免每个人都有权将“派生”项目中的更改合并回“基础”项目。
此外，您可以在同一个团队项目中创建多个团队，您可以将它们嵌套以方便层次结构。 如果您有兴趣，可以查看此博客 ，其中显示了如何配置它。
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.
更多推荐
发布评论