我们的构建服务器出现了问题，尽管我们认识到存在更改，但没有从源代码管理中检查修改。
它被追踪到控制文件夹（不确定它的真实名称是什么），现有的工作版本使用 _svn。清除工作文件夹会强制进行新的完整结帐，我注意到现在控制文件夹是 .svn。看起来我们的集成例程最初是使用 _svn 检查代码，但现在它使用的是 .svn。
集成期间使用的 svn.exe 来自 VisualSVN 服务器，我可以将其设置为再次使用 _svn 吗？
我不知道原始工作副本是如何使用 _svn 的！- 我们只使用过 VisualSVN 服务器并且没有改变它。
我们根据建议将 TortoiseSVN 设置为使用 _svn，这对 Visual Studio 更有效，并且还在构建服务器上安装了 TortoiseSVN，以备不时之需。这可能是原因吗？
这真的有必要吗？由于 MSBuild 是 Microsoft 的，因此是否像 Visual Studio 那样推荐它？
关于 _svn 与 .svn 的业务仅是 Visual Studio Web 项目的问题（而且我相当肯定它已在 VS2005 中修复），这不是一般的“_svn 与 VS 配合得更好”的事情。
这也只是一个工作副本问题，而不是存储库问题 - 即 SVN 的一些用户是否使用设置为执行 _svn 的客户端和一些使用 .svn 无关紧要 - 存储库不会知道或关心 - (除非您最终以某种方式最终将这些 _svn/.svn 文件加载到存储库中，这将是极端混乱的。）
除非您有绝对的具体证据表明 .SVN 给您带来了问题，否则我会尽可能地坚持这一点。
我一直在将 .svn 与 Visual Studio 2008 和 2005 以及我们的 CC.Net 集成服务器（使用 MSBuild）一起使用，没有任何问题。我会坚持使用 .svn 格式。
http://subversion.tigris.org/svn_1.3_releasenotes.html
需要阅读“官方支持 Windows '_svn' 目录（客户端和语言绑定）”部分
并且需要注意您正在阅读几年前的文档，这可能是相关的，也可能不是相关的。
据我所知 _svn 是需要的，因为当 WebApplications 的一个目录以点开头时会出现问题。