TeamCity 未从 SubVersion 检索所有文件答案

【问题标题】：TeamCity is not retrieving all files from SubVersionTeamCity 未从 SubVersion 检索所有文件
【发布时间】：2011-08-24 21:23:12
【问题描述】：

我正在使用 TeamCity 设置 QA 服务器。我刚刚向 TeamCity 添加了一个项目及其配置，但注意到它没有从我设置的 VCS 根目录中获取所有文件。

其他项目没有这个问题，而且这个项目也没有从有问题的根目录中检索任何文件。它是相关 VCS 根目录的 /website/bin 子目录中的少量 DLL 文件。

构建日志没有暗示这里有任何问题：

[11:43:46]：[更新来源：服务器端结帐...] 为 VCS 根目录构建增量补丁：网站静态

是所有日志提及的内容。

编译没有任何问题，只有当浏览到基于 Umbraco 构建的站点时，Microsoft.ApplicationBlocks.Data.dll（以及其他）才具有没找回来。

此服务器上已经设置了其他基于 Umbraco 的站点，但没有遇到此问题。

是否有人对可能发生的事情有任何建议，或者至少我可以从哪里开始寻找？

非常感谢。

【问题讨论】：

请查看管理 | 中的 teamcity-vcs.log服务器配置 |服务器日志，如果在结帐期间发生任何错误或警告。
只是另一种尝试：可能没有正确确定代码差异。您是否尝试在项目配置的“版本控制设置”部分中选择“在构建之前清理所有文件：”？
金，谢谢你的建议。不幸的是，日志中没有显示错误，选择“全部清除...”没有任何区别。某些 DLL 仍然没有从存储库中复制。还有其他建议吗？
我也有同样的问题。它似乎只影响具有多个句点的文件，例如 Microsoft.ApplicationBlocks.Data.dll 或令人讨厌的 MyCompany.foo.bar.sln。在同一构建服务器上从命令行运行 svn checkout，作为同一用户，检查正常。我对 TeamCity 所做的唯一更改是从 Professional 升级到 Enterprise 许可证，受影响的构建是第一个超过 20 构建配置限制的构建。当然，相关性，但这就是我必须继续下去的全部内容。

标签： svn teamcity

【解决方案1】：

有时你必须踢它才能让它运行。 :-) 当我们遇到这种类型的行为时，我们在构建配置视图中选择“Enforce clean checkout”，然后再次按运行。

【讨论】：

尼克拉斯，谢谢你的建议。我试了一下，但最终还是在同一个地方。某些 DLL 根本不是从颠覆中带来的。鉴于这些是静态 DLL，预计不会更改，我只是手动复制了它们，并将其添加到该站点的文档中。
这很奇怪...如果您在构建服务器上手动执行 svn checkout 会发生什么？不是通过 TeamCity 吗？
这很好用。我最终不得不咬紧牙关，记录下这一点怪异。幸运的是，它只发生在单个站点上的静态库中。它并不完美，但我们可以忍受。
所以它最终在 TeamCity 中起作用了？还是只有手动结帐？（对不起，如果我很愚蠢......）
它适用于手动结帐。试图弄清楚发生了什么事情所花费的时间越来越多——当时可以进行许多手动检查。由于它是静态文件，而不是那些由代理更改或构建的文件，因此似乎最好放手。

【解决方案2】：

在我的情况下（团队城市服务器 8.0.3），当团队城市没有更新外部 svn 文件夹的一部分时，我们遇到了一个奇怪的情况。根据 8.0.4 服务器的发行说明，存在与外部工作相关的问题：http://youtrack.jetbrains.com/issue/TW-31507，但升级到新服务器也没有帮助。

解决方案是将 VCS 根目录的外部设置从“完全支持（加载更改和签出）”切换为“签出，但忽略更改”。之后，我们的外部文件夹已正确更新。

希望这有助于解决此类问题。

【讨论】：

【解决方案3】：

如果您的配置的版本控制设置下的 VCS 根目录中有签出规则，它们可能会选择性地仅签出不包括 /website/bin 的根目录的某些部分

您可以清理结帐并重试吗？它是通过版本控制设置完成的：

【讨论】：

没有为此根配置结帐规则，但我会考虑 Kim 的建议并回复大家。
试过了，没用:(这个被分配到了莫名的诡异宝库。

【解决方案4】：

冒着在这里回答我自己的问题看起来很糟糕的风险，我不得不说这个奇怪的问题没有答案。最终，我放弃了，因为要花太多时间来证明这样一个小而令人困惑的问题是合理的。事实证明，解决方法是在需要时手动签出。

【讨论】：