在多个供应商项目中使用 TFS 和 SVN 的可能解决方案？
我正在努力建立一个源代码控制解决方案，该解决方案将允许多个供应商为单个项目做出贡献（单个安装中的多个 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。
上述方法的相对缺点和优点是什么，以及使用什么工具会让我的生活更轻松吗？
I'm working to establish a source control solution that will allow multiple vendors to contribute to a single project (multiple Sitecore CMS sites in a single installation). Ideally we'd like to go with TFS as it seems to fit our in-house requirements and support best. Some of our vendors, however, prefer SVN. If we choose to go with TFS there seem to be a number of possible solutions to this.
1) Vendors commit to using TFS directly, using MS tools and CALs(e.g. Visual Studio for back end devs and tfs.exe etc for front end).
2) Vendors use TFS, plugging in with and adaptor to their current SVN tools (SVN Bridge / SVN Tortoise) - still requires a CAL per developer.
3) Vendors use a single CAL to establish a codebase from the TFS which they then use as an SVN repository. Vendors use SVN locally but use continuous integration between the SVN repository and the TFS to keep in synch.
The third option looks cheaper in licensing terms, but would add considerable complexity and developer time in the synching, and would presumably lose check-in info on a per developer basis (a single dev would check in all changes by his team to the TFS).
We don't actually need a great level of detail and sophistication, just basic functionality. The vendors are responsible for their teams, we don't even really need to know who did what at that level, just that it came from vendor A or vendor B.
What are the relative drawbacks and benefits of the approaches above, and what tools would make my life easier?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如您所指出的，您在这里确实有几个选择：
如果您的供应商只是想使用类似 Windows 资源管理器的集成（类似于 Tortoise 工具），他们可以安装包含资源管理器集成的 TFS Power Tools。虽然此选项将要求您的供应商学习新工具（因此一开始可能会有点令人沮丧），但这肯定会具有最少数量的“移动部件”和损坏的可能性。
这可能是最困难的路线。虽然 SVNbridge 在很多方面都很出色，但它可能无法提供用户所需的所有功能，例如分支和合并。
及时迁移提供了SVN 到 TFS 迁移工具 这对于第一次从 SVN 迁移到 TFS 很有用，但是（如果我记得的话）确实有一些手动解决步骤，这会使其更难以以自动化方式使用。然而，这可能值得研究如何将其用于同步。不过，在这一点上，您应该就 CAL 许可问题咨询您的 Microsoft 联系人：使用自动化工具在 TFS 和其他系统之间进行同步并不一定会消除 CAL 限制。
As you point out, you do have several options here:
If your vendors simply want to use Windows Explorer-like integration (similar to Tortoise tools) they can install the TFS Power Tools which include Explorer integration. While this option will require your vendors to learn new tools (and thus may be a bit frustrating at first), this will certainly have the fewest number of "moving parts" and potential for breakage.
Is probably the most difficult route. While SVNbridge is excellent at many things, it will probably not provide all the functionality that your users will require, for example, branching and merging.
Timely Migration offers a SVN to TFS Migration Tool that is useful for a first-time SVN to TFS migration, but (if I recall) does have some manual resolution steps that would make it more difficult to use in an automated manner. However, this may be worth investigating how it could be used for synchronization. On this point, however, you should consult with your Microsoft contact regarding CAL licensing: using an automated tool to synchronize between TFS and another system does not necessarily remove CAL restrictions.