我正在努力建立一个源控制解决方案，允许多个供应商为单个项目（单个安装中的多个Sitecore CMS站点）做出贡献。理想情况下，我们希望使用TFS，因为它似乎符合我们的内部要求和最佳支持。但是，我们的一些供应商更喜欢SVN。如果我们选择使用TFS，似乎有很多可能的解决方案。
1）供应商承诺使用MS工具和CAL直接使用TFS（例如Visual Studio用于后端开发人员和tfs.exe等用于前端）。
2）供应商使用TFS，插入和适配当前的SVN工具（SVN Bridge / SVN Tortoise） - 每个开发人员仍需要CAL。
3）供应商使用单个CAL从TFS建立代码库，然后将其用作SVN存储库。供应商在本地使用SVN，但使用SVN存储库和TFS之间的持续集成来保持同步。
第三个选项在许可条款上看起来更便宜，但会在同步中增加相当大的复杂性和开发时间，并且可能会在每个开发人员的基础上丢失签入信息（单个开发人员会检查他的团队的所有更改） TFS）。
我们实际上并不需要高水平的细节和复杂性，只需要基本的功能。供应商对他们的团队负责，我们甚至不需要知道谁在那个级别做了什么，只是来自供应商A或供应商B.
上述方法的相对缺点和好处是什么，以及哪些工具可以让我的生活更轻松？
答案 0 :(得分：1)
正如您所指出的，这里有几个选项：
如果您的供应商只想使用类似Windows资源管理器的集成（类似于Tortoise工具），他们可以安装包含Explorer集成的TFS Power Tools。虽然这个选项要求你的供应商学习新工具（因此最初可能会有点令人沮丧），但这肯定会有最少数量的“活动部件”和破损的可能性。
可能是最困难的路线。虽然SVNbridge在许多方面都非常出色，但它可能无法提供用户所需的所有功能，例如分支和合并。
及时迁移提供SVN to TFS Migration Tool，这对于首次进行SVN到TFS迁移非常有用，但是（如果我还记得）确实有一些手动解决步骤会使其更难以在自动化方式。但是，这可能值得研究它如何用于同步。但是，在这一点上，您应该咨询您的Microsoft联系人有关CAL许可的信息：使用自动化工具在TFS和其他系统之间进行同步不一定会删除CAL限制。