使用 TFS 和 Sharepoint 将规范与代码一起分支的好方法是什么？
我们是一家软件产品公司，我们的产品代码库自然会针对不同的项目进行分支。我们当前使用配置为在 SharePoint 2007 中存储文档的 TFS2008。这两个版本都将从 TFS 开始更新到 2010 版本。
我们希望对我们的规范进行分支（而不仅仅是版本），以便任何代码分支的任何版本都可以针对规范的匹配版本进行测试。
在我看来，我们可以：
- 将我们的规范保留在 SharePoint 中，使用 SharePoint 搜索和版本控制，并通过使用命名约定或子目录来伪造分支问题
- 将我们的文档从 SharePoint 移动到正确的 TFS 中。享受免费的版本控制和分支，并静静地哀悼我们失去的 SharePoint 文档管理优势
- 找到一些神奇的插件，让我们两全其美？
有人对这些选项有任何经验吗？
We are a software product company and our product codebase naturally gets branched for different projects. We currently use TFS2008 configured to store documents in SharePoint 2007. Both of these will be updated to 2010 versions, starting with TFS.
We'd like to branch - and not just version - our specifications so that any release from any code branch can be tested against a matching version of the spec.
It seems to me that we can either:
- Keep our specs in SharePoint, using SharePoint search and versioning, and fake the branching issue by use of naming conventions or subdirectories
- Move our documents from SharePoint into TFS proper. Enjoy the free versioning and branching, and quietly mourn our lost SharePoint document management goodness
- Find some magic plug-in that gives us the best of both worlds?
Does anyone have any experience of any of these options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这实际上取决于您的实际需求。如果您的商店中有很多人只能偶尔访问一次文档，那么 SharePoint 的优势可能会胜过 TFS 中的同步功能。
如果您只有几个业务分析员，那么同步功能可能会胜过 SharePoint。
请注意，当您将文档存储在 TFS 中时，每个访问文档的用户都需要一个 CAL。
It really depends on what your real needs are. If you have a shop where you have many people who have to access the documents only once in a while, probably the SharePoint advantage wins over the sync feature in TFS.
If you only have a few business analists, then probably the sync feature wins over SharePoint.
Be aware that when you store the documents in TFS, you need a CAL for every user that accesses the documentation.
我想我会通过考虑这一点来选择替代方案 1：如果您的文档例如在 MS Word 中，则分支在合并方面不会给您带来任何好处。这永远不适用于二进制文件。
如果您的文档实际上是基于文本的文档，考虑到您在 Sharepoint 中获得的搜索功能、视图等，我想我仍然会选择 1。
I think I would go for alternative 1 by considering this: If your documentation is e.g. in MS Word, branching will give you nothing in terms of merging. That will never work with binary files.
If your documentation actually are text-based documents, I think I'd still go for 1, considering search capabilities, views etc. that you get in Sharepoint.
这是我根据此处的答案和进一步的实验提出的解决方案。
首先，更多背景知识：
您可以从 Word 内部在 SharePoint 中保存的 Word 2007 文档版本之间进行非常有用的比较 [1]（菜单：审阅 > 比较 > 比较 > 特定版本...）和 [2]将 Word 文档的不同版本作为单独的文件进行比较（菜单：“查看”>“比较”>“比较”>“比较...”），但您无法直接在 TFS 中进行版本比较，因为它会在二进制文件上出现问题。
这使您可以轻松地比较 TFS 分支之间的同一文档，因为文档的两个版本都在您的文件系统上（因为 TFS 2008 通过目录实现分支），因此您只需使用上面的选项 [2]。它还为您提供了一种不太容易的工作方式来比较同一分支中的不同版本（或者通常是非当前版本） - 您将非当前版本下载为重命名的文件，然后像以前一样进行文件比较。
现在的建议是：
我只是建议我们在 SharePoint 中创建所有规范，并在那里创建一个分支文件夹树来镜像 TFS 中的分支文件夹。
如果出现需求，我们可以在分支发布时将相关规范的快照复制到 TFS 中，但我希望分支规范不会更改发布后日期，或者如果更改，SharePoint 版本控制将对我们来说处理得足够好。
Here's what I've proposed as a solution, based on the answers here and on further experimentation.
First, some more background:
You can do very usable comparisons [1] between versions of a Word 2007 document held in SharePoint from inside Word (menu:Review > Compare > Compare > Specific Version...) and [2] between different versions of a Word document as separate files (menu:Review > Compare > Compare > Compare...) but you can't do version comparisons directly in TFS because it barfs on binaries.
This leaves you with an easy work-round for comparing the same document between TFS branches because both versions of the document are there on your file system (since TFS 2008 implements branching via directories) so you just use option [2] above. It also gives you a less easy work-round for comparing different versions in the same branch (or non-current versions generally) - you download the non-current versions as re-named files, then do the file comparison as before.
Now the proposal:
So I'm simply proposing we do all our specification creation in SharePoint, and create a branch folder-tree there to mirror the branch folders in TFS.
If the requirement arises, we can copy a snapshot of the related specs into TFS when the branch is released, but I'm hoping that either the branched specs won't change post-release date, or that if they do, SharePoint versioning will handle it well enough for us.