使用 TFS 搁置集的原因之一是我不同意代码审查，但这是我当前项目中遵循的做法。我看到使用 TFS 搁置集对代码审查来说不是一个好主意的原因是
有人可以为我提供一些可以支持或反对TFS 搁置方法进行评论的指针，以便我对这种方法深信不疑，或者我可以提出一个不使用这种方法的案例？
我认为微软在这一点上与你有很多不同，因为 TFS 11 和 Visual Studio 11 中的新代码审查功能是围绕搁置集构建的。真正的问题可能更多地在于团队如何运作以及如何在产品中分配任务。
如果任务已被拆分，使得它们几乎没有依赖关系，并且在同一区域工作的人可以紧密合作，那么您不会在合并和签入方面遇到任何问题。如果您的任务需要更多时间，请定期从开发分支获取最新版本，以便您始终保持最新状态。
如果您看到 Reviewer 太慢并且搁置集正在排队，都在等待被审查，那么这就是其他真正问题可能发生的地方。当一项任务完成后，它应该尽快被审查，而不是躺在那里等待审查。如果审核时间超过 24 小时，那么这可能会成为一个真正的问题。您可以通过由其他人进行同行评审或让更多的评审员加入团队来缓解这种情况。
如果一切都失败了，您可以进行事后审查（审查变更集而不是货架），TFS 11 和 Visual Studio 11 也支持这种情况。
我个人的偏好是信任我团队中的开发人员，因此我们主要进行签入后审查。如果我们有新成员或非常初级的成员，那么我将确保有更高级的开发人员可以代替进行第一次预检。
也可以看看：
Shelveset 没有变更集的自然顺序。这会导致很多合并冲突。
我在这里看不到你的意思，对你来说什么是“自然排序”？当您开始在团队中工作时，变更集的年表不会遵循给定的顺序。
如果开发人员在审核之前无法签入代码，则依赖审核者，如果审核者在短时间内不进行审核，这些搁置集可能会干扰其他任务。
同样，您在“常规任务开发”中遇到相同的情况，这不是因为您在任务 B 之前启动任务 A，您将在 B 之前签入任务 A（除非 B 依赖于 A，但这不是重点）。将审查视为任务开发工作流程的最后一步。对审阅者的依赖确实让事情变得更复杂一些，但这是为了有一个稳定的构建并且有符合公司标准的代码。
与其他开发人员的协作变得很痛苦，因为现在您需要传递搁置集而不是签入代码，这可能会在未来再次导致合并冲突。
你知道比搁置更容易的东西吗？您是否喜欢在 zip 文件中发送包含修改后代码的电子邮件？当您不想影响引用时，搁置集是在开发人员之间共享代码的更简单的方法。再次在这里，我看不到您提到的合并冲突问题。
这里有一些建议：
当有人取回另一个开发者的搁置集时，假设开发者 A 创建了一个搁置集，而开发者 B 想要查看它，请确保开发者 B 有一个单独的干净且专用的工作区来取消搁置。您不想在常规的“开发”工作区中搁置一些东西。用于代码审查的专用工作区缓解了您提到的合并冲突问题。
理论上，所有内容都应该在集成到目标分支之前进行审查。话虽如此，实际上这样做更难，所以如果你的团队没有这种流程的习惯，就不要力求做到完美。熟悉他正在处理的应用程序的高级开发人员可以被授权在审查之前签入。这完全是一个权衡问题，在这种情况下，您可以获得灵活性和更流畅的开发体验，但您的引用可能会在质量和稳定性方面受到影响。这里没有真正的赢家，这是您根据对您来说重要的事情做出的选择。
不要使用分支进行代码审查。
我同意在 VS/TFS 中通过shelfset 进行的代码审查体验有些不完整，但它比替代方案要好得多。微软意识到他们在这方面可以做得更好，这体现在 VS11/TFS11 中所做的改进。在下一个版本中，您将拥有真正的代码审查体验，仍然基于搁置集，但参与者之间的通信系统更加完整。这种改进是在“我的工作”体验中进行的，现在事情变得更加顺畅。尝试 tfspreview.com 和 VS11 beta 或阅读一些博客文章 (Brian Harry) 以获取更多信息。这是您会感兴趣的链接。
问题不在于搁置。如果您一直在等待同行来审查您的代码，那么代码的存储方式不会有太大的不同。也就是说，搁置集安全地存储在您的计算机之外的一个评论者可以访问的位置，所以我认为这是一个很好的解决方案。另一种方法是签入，传递变更集并在它没有通过集合或传递拉链时恢复？两者都有明显的缺点。
那么，真正的问题是您是否应该在签入之前要求进行代码审查？