我尝试为新的 TFS 存储库设置新结构,并尝试将团队项目映射到如下结构中的子文件夹:
根
- 截断
- (团队项目)Proj1
- 子项目1
- 子项目2
- 子项目...
- (团队项目)Proj2
- ...
- (临时项目)...
- 全球的
- (团队项目)Proj1
- 发布
- 项目1
- 子项目1 V3.5
- Proj1(分公司)
- SubProj2(分支)
- SubProj4(分支)
- 全球(分公司)
- Proj1(分公司)
- 子项目1 V3.6
- Proj1(分公司)
- SubProj2(分支)
- SubProj4(分支)
- 全球(分公司)
- Proj1(分公司)
- 子项目2 V2.1
- Proj1(分公司)
- SubProj1(分支)
- SubProj7(分支)
- 全球(分公司)...
- Proj1(分公司)
- 子项目1 V3.5
- 项目2...
- 项目1
- 第 3 方库
- 库1
- 库2
这是关于到目前为止我们在不同的 scc 系统中使用的结构,我们尝试将它们全部统一到新的 TFS 存储库中。
在我们看来,这种结构有几个优点:
- TFS(工作项,构建)的团队项目功能为公司中的每个团队分开,即构建列表不会太长,无法搜索以找到特定的子项目。
- 要将存储库映射到本地硬盘驱动器,我们只需同步存储库的“Trunc”路径和“3rd party libs”路径,并避免将过去 15 年的所有分支加载到每个硬盘(千兆字节的垃圾)。Trunc 主子文件夹仅包含我们每个人每天使用的活动源代码。
- 要修复/重新编译某个特定分支,我们只检查版本中的特定子文件夹(即 /Release/Proj4/SubProj2 V4.5/*),它只有几兆字节大小。重建后,我们可以从硬盘中删除该子文件夹的映射...
我在网上查了一下,但似乎 TFS 的结构过于严格,团队项目只能位于存储库的根目录中。那可能吗?没有办法在一个位置管理团队项目并在另一个位置处理发布分支吗?那么,从多个团队项目中使用的自行开发的公共库呢?
在我们的存储库(几个)中,有数百个按不同主题分组的项目。我想为主题制作团队项目,并使用单独的 .sln 文件通过团队项目中的不同子文件夹管理实际项目。但我真的很想将发布分支与所有活动来源分开......
有没有办法处理这个?
感谢您的回答,我害怕听到您实际回答的内容...
我们有几个使用相同基础库的团队项目。在发布分支中,我们通常也会对这些基础库进行分支,以拥有这些库的稳定立场。在 TFS 中,当我为应用程序使用不同的团队项目并为基础库使用单独的团队项目时,我是否可以制作我的 App1 的发布分支,即“App1 V3.2”,其中包含我的应用程序分支的路径以及使用的库的路径?或者,每当我创建任何应用程序的发布分支时,我是否也必须分支基础库团队项目?那么我怎样才能找到正确的 App1 版本和我的基础 lib3 和基础 lib5 的正确版本?
为什么 MS 的一切都必须如此复杂?乍一看,它是一个很酷的系统,但当您尝试使用它时,事实证明您必须彻底改变您的工作方式,使其变得更糟......
我可以仅将 TFS 用作 scc,例如 perforce、subversion 或其他吗?有没有办法摆脱团队项目根级别?或者有没有办法定义子团队项目?
好的,当我决定创建一个大团队,即“开发”并拥有类似于我的初稿的子文件夹结构时,项目/构建呢?我可以将 ie 构建在代表实际应用程序的 groupbs 中(我在草稿中将其命名为子项目)吗?否则,我们将有一个“开发”团队项目中的大量构建列表以及属于公司中完全不同团队的数千个项目......