我刚刚将我的代码从 Perforce 迁移到了 TFS。一切看起来都不错,但有一个问题是从一个解决方案到另一个解决方案的正向和反向集成。这是我的表演终结者。
有两种不同的解决方案,两个解决方案中共有 2 个项目,但分别有不同的副本。因此,前向集成是将整个应用程序从 sol1 合并到 sol2,以解决常见项目中的冲突。解决后将代码合并回解决方案 1(反向集成)。需要理解的是,只需要合并常见的项目,其他的都可以排除。
可以在 TFS 中进行类似的设置吗?
我刚刚将我的代码从 Perforce 迁移到了 TFS。一切看起来都不错,但有一个问题是从一个解决方案到另一个解决方案的正向和反向集成。这是我的表演终结者。
有两种不同的解决方案,两个解决方案中共有 2 个项目,但分别有不同的副本。因此,前向集成是将整个应用程序从 sol1 合并到 sol2,以解决常见项目中的冲突。解决后将代码合并回解决方案 1(反向集成)。需要理解的是,只需要合并常见的项目,其他的都可以排除。
可以在 TFS 中进行类似的设置吗?
是的,这种情况在 TFVC 中是可能的,但不是很常见。你有几个选择:
在解决方案级别创建一个分支根并将文件从解决方案一合并到解决方案二。作为合并操作的一部分,排除您不想合并的文件。稍后您可以在文件夹级别向后和向前合并。
创建文件夹关系,但不要将文件夹变成分支根。这允许您随时将一个文件夹与另一个文件夹合并,但不会将这些文件夹显示为分支本身
在每个项目级别创建一个分支根并单独合并每个项目。这有几个缺点(因为在这种情况下您不能分支整个解决方案,因为不能嵌套分支根)。
或者您可以以不同的方式解决问题:
创建一个包含公共代码的单独解决方案并使用包管理(NuGet 包发布)来共享两个解决方案之间的依赖关系(本质上是创建 3 个解决方案)。
使用工作区映射将通用代码保留在版本控制中的单个位置,并将代码映射到磁盘上的不同位置。您可以在代码中使用编译器指令或配置或不同的抽象(接口、抽象类)将源代码编译成不同的版本。
我得到了确切的解决方案,这或多或少是您提供的第一个选项 Jesse。基本上我们需要为其中一个解决方案创建公共项目,然后将它们分支到另一个解决方案中。在稍后的时间点,我们可以将它们从解决方案 1 合并到 2,签入解决方案 2 中的合并文件,然后从解决方案 2 合并到 1,并签入解决方案 1 中的合并文件。