我目前正在工作中建立一个持续集成环境。我们正在使用 VisualSVN 服务器和 CrusieControl.NET。有时构建会失败，症状是 CruiseControl.NET 工作副本中存在冲突。我相信这是由于我设置 Visual Studio 解决方案的方式。希望我们在这种环境中运行的项目越多，我们对如何设置它们的理解就会越好，所以我不会质疑为什么会在这个阶段发生冲突。为了修复构建，我删除了工作副本并强制构建新的构建 - 这每次都有效（当前）。所以我的问题是：删除工作副本是否是持续集成构建过程的有效部分，我该怎么做？
我已经尝试过解决方案，包括 MSTask 和从命令行调用 delete，但我没有任何运气。
抱歉这么罗嗦 - 干得好，这是一个测试版 :)
在构建之前或之后进行完全删除是一种很好的做法。这意味着您的构建环境不可能拾取过时的文件。您的构建完全符合存储库中的内容。
正如我使用 Nant 所做的那样，可以删除工作副本。
在 Nant 中，我会在自己的文件夹中拥有一个干净的脚本，而不是我要删除的那个，然后从 CC.net 调用它。
我认为这也应该可以通过批处理文件实现。看看 rmdir 命令http://www.computerhope.com/rmdirhlp.htm
@pauldoo
我更喜欢我的 CI 服务器进行完全删除，因为当我进行发布构建时我不希望有任何意外，这应该始终从干净的状态完成。但它应该能够同时处理两者，没有理由不
@jamie：使用持续集成服务器时可能无法每次都进行干净构建的原因之一——构建时间。在我参与过的一些项目中，干净的构建需要 80 多分钟（一个由数千个 C++ 文件组成的嵌入式项目，需要检出然后针对多个目标进行编译）。在这种情况下，您必须权衡快速反馈的好处与干净构建会捕获增量构建不会捕获的东西的可能性。在我们的案例中，我们致力于改进和并行化构建过程，同时允许在我们的 CI 机器上进行增量构建。我们确实遇到了一些问题，因为我们没有进行干净的构建，但是通过每晚或每周进行一次干净的构建，您可以消除风险，而不会丢失 CI 机器的快速反馈。
如果您查看 CC.NET 的jira，则会签入一个补丁来实现 CleanCopy for Subversion，这正是您想要的，只需在源代码控制块内将 CleanCopy 设置为 true，就像使用 TFS 一样。
对于任何构建过程来说，在进行任何重要构建之前进行“清理”是非常常见且通常是一种很好的做法。这可以防止以前构建的任何“工件”污染输出。
清理本质上是您通过删除工作副本所做的事情。
@布拉德·巴克
清洁意味着只清除构建产品。
删除工作副本也会删除其他所有内容（源文件和项目文件等）。
一般来说，如果您的构建机器可以在不进行完全删除的情况下运行，那就太好了，因为这复制了普通开发人员所做的事情。它在更新期间发现的任何冲突都是对您的开发人员可以预期的早期警告。
@杰米
对于正式版本，是的，最好进行完全干净的结帐。所以我想这取决于构建的目的。