使用TFS 2013代码审查和替代源代码管理

我们正在使用TFS进行日常工作管理，但目前无法将其用于源代码管理-我们正在使用SVN

尽管如此，我还是希望确保我们的所有工作项在关闭之前都经过了代码审查，并且任何代码审查操作都得到了跟进。关于如何使用TFS以最少的手动步骤跟踪此问题，有什么建议吗

我还关心确保代码审查步骤没有被跳过，以及是否已经发生以及是否所有结果操作都已关闭的可审核性。如果我查看一个已结束的任务，我如何轻松地判断它是否发生了代码复查

（可选）要求每个SVN更改都引用TFS中带有签入注释的工作项编号

TFS中的工作项上有一个“链接”选项卡。代码签入后，应创建另一个“任务”类型的工作项（或用于代码审阅的任何内容），并链接到此链接选项卡上的主要工作项，以请求对该工作项进行代码审阅。应参考需要审查的SVN修订号

我不太熟悉SVN，但我认为有一种方法可以使用如下分支。为已审核的代码维护一个单独的分支。只有代码审阅者才能合并到该分支中。如果TFS中存在正确的工作项，并且代码审阅者批准并合并代码，则代码才能进入TFS。我习惯于Mercurial和TFS，它们合并代码非常容易。如果在SVN中合并不容易，则可能需要不同的解决方案

如果某个工作项上存在链接的任务，则您知道代码已签入，并且正在进行代码审阅。如果链接存在，并且已解析链接的工作项，则您知道代码审阅已完成。如果该链接不存在，那么您知道该工作项的代码尚未签入（或者至少它不在已审阅的代码分支中，并且不打算存在）

---

我们已决定编辑TFS工作流，以便在“已解决”之后包含额外的“审查中”状态。这使我们可以使用现有的任务板，而无需创建单独的审查任务，或将任务标题编辑为“审查中：…”

您能否更具体地解释您正在处理的挑战？例如为什么不简单地为每个代码审阅请求使用一个任务呢？这将是一个备份选项，但它依赖于人们记住创建任务，因此很难跟踪是否有人在没有创建审阅任务的情况下关闭了一个开发任务。我的观点是，您应该将这些问题添加到您的问题中，以便我们确切地知道哪些约束您正在尝试申请。好的，谢谢，问题的编辑是否涵盖了它？这是否有助于解决问题：谢谢您提供上述建议。在与微软交谈之后，似乎如果不定制TFS（我们在我的组织中无法做到），就不可能满足我的要求。作为一种解决方法，我们将使用“resolved”列表示“ready for code review”，使用“closed”列表示代码评审通过。我觉得为每个任务添加一个重复的链接项会增加太多的开销。你一年多前提出的问题不清楚，这不是答案。考虑删除原问题为将来谷歌搜索寻求帮助TFS@Jonathon如果我试图删除它，它说我不能，因为它有答案。