2

我正在努力建立一个源代码控制解决方案，该解决方案将允许多个供应商为单个项目做出贡献（单个安装中的多个 Sitecore CMS 站点）。理想情况下，我们希望使用 TFS，因为它似乎最符合我们的内部要求并提供最佳支持。然而，我们的一些供应商更喜欢 SVN。如果我们选择使用 TFS，似乎有许多可能的解决方案。

1) 供应商承诺直接使用 TFS，使用 MS 工具和 CAL（例如用于后端开发的 Visual Studio 和用于前端的 tfs.exe 等）。

2) 供应商使用 TFS，插入并适配到他们当前的 SVN 工具（SVN Bridge / SVN Tortoise）——每个开发人员仍然需要一个 CAL。

3) 供应商使用单个 CAL 从 TFS 建立代码库，然后将其用作 SVN 存储库。供应商在本地使用 SVN，但使用 SVN 存储库和 TFS 之间的持续集成来保持同步。

第三种选择在许可条款上看起来更便宜，但会在同步中增加相当大的复杂性和开发人员时间，并且可能会丢失每个开发人员的签入信息（单个开发人员会签入他的团队对 TFS 的所有更改） .

我们实际上不需要大量的细节和复杂性，只需要基本的功能。供应商对他们的团队负责，我们甚至不需要知道谁在那个级别做了什么，只要它来自供应商 A 或供应商 B。

上述方法的相对缺点和优点是什么，哪些工具可以让我的生活更轻松？

4

1 回答 1

1

正如您所指出的，您确实有几个选择：

  1. 如果您的供应商只是想使用类似于 Windows Explorer 的集成（类似于 Tortoise 工具），他们可以安装包含 Explorer 集成的 TFS Power Tools。虽然此选项将要求您的供应商学习新工具（因此一开始可能会有点令人沮丧），但这肯定会具有最少数量的“活动部件”和损坏的可能性。

  2. 大概是最难走的路线了。虽然 SVNbridge 在很多方面都很出色，但它可能无法提供用户需要的所有功能，例如分支和合并。

  3. Timely Migration 提供了一个SVN 到 TFS 的迁移工具，该工具对于首次 SVN 到 TFS 的迁移很有用，但是（如果我记得的话）确实有一些手动解决步骤，这会使以自动化方式使用它变得更加困难。但是，这可能值得研究如何将其用于同步。但是，在这一点上，您应该就 CAL 许可咨询您的 Microsoft 联系人：使用自动化工具在 TFS 和另一个系统之间进行同步并不一定会消除 CAL 限制。

于 2011-04-28T20:21:58.910 回答