作为SO的长期潜伏者，我正在提出一个关于CruiseControl.NET，Subversion和远程存储库的棘手问题。这是问题所在：
在Windows Server 2008 SP2上运行一个远程Subversion 1.6.6存储库，使用Apache 2.2.14作为网关启用端口80和443上的访问 - 我们将未加密的流量重定向到安全端口，我们有一个正确的 - 已配置的SSL层使用自签名证书运行。这一切都有效 - 我可以将浏览器从我的本地计算机（XP SP2或Server 2008 SP2）指向此存储库，轻松地通过证书验证，针对存储库ACL进行身份验证，并查看其中的内容。同样，在我的本地机器上执行的SVN命令（在命令行或通过TortoiseSVN）可以完美地工作。
现在添加CruiseControl.NET 1.4.4.83 - 在我的本地计算机上运行一个简单的脚本，从远程存储库中提取一些源代码，并构建一个非常基本的应用程序。这个相同的脚本与本地存储库完美配合，因此唯一的区别是Subversion URL，它现在指向远程服务器。
如果我在自己的帐户下在命令行shell（ccnet.exe）中运行CC.NET，它就可以运行。
如果我将CC.NET作为服务运行（ccservice.exe），它会失败;默认情况下，它作为LOCALSERVICE运行，但我已经将其更改为使用我的凭据运行。在这种模式下，发出的第一个Subversion命令（SVN LOG）失败，抱怨它无法连接到服务器。
我花了四五天时间调查这个;我知道这不是防火墙类型的问题，因为CC.NET在命令行shell中发出的命令完全相同，当然我可以通过TortoiseSVN和浏览器连接到远程服务器。这不是SSL和/或证书妨碍了，因为我已经导入了证书 - 再次，这在使用TortoiseSVN，浏览器或命令行的SVN命令的'手动'模式下工作正常。这不是DNS解析问题，因为我可以指定远程服务器的实际IP地址，但仍然无法连接 - 但如果我在命令行模式下运行，当然连接正常......
我甚至通过CC.NET源代码下载并徘徊，看看是否有任何奇怪的事情发生。据我所知，在服务模式下运行时发出命令的唯一区别是，已经进行了AllocConsole调用，以便为Subversion命令进程准备一个控制台，以便在它们生成时锁定。
在这个阶段，我可以做的最好的猜测是，AllocConsole会话在某种程度上与标准命令行会话有根本的不同 - 即使服务是在我的用户凭据下运行，不知何故AllocConsole没有'适当的'网络访问。但是，我不太了解AllocConsole或CC.NET源代码能够证明这一点，因此我处于僵局。
目前，我正在命令行模式下运行CC.NET;但是，这只是感觉不尽如人意，因为我们更喜欢在服务模式下运行它（这对我们本地域中的存储库工作正常），以避免在机器启动时创建计划任务来启动它。
有人有任何建议吗？
答案 0 :(得分：1)
破解了。这不是防火墙问题，而是代理问题。
我们在这里使用Bluecoat（是的，我知道，不是我的电话）以及Subversion'服务器'文件，它位于我们所有开发人员的'C：\ Documents and Settings \ All Users \ Application Data \ Subversion \'中PC有一个条目允许我们绕过代理以访问特定的外部存储库。但是，我们倾向于主要使用TortoiseSVN，并通过属性表访问此文件 - 直到现在，还没有意识到它是Subversion文件，而不是TortoiseSVN文件。
当然，由于我们不在构建服务器上使用TortoiseSVN，因此我们从未弄乱过'servers'文件。但是，现在CruiseControl.NET需要访问外部存储库（之前它只与我们的内部存储库进行了对话），它无法通过Bluecoat路障。
一旦拼图点击到位，我在构建框中创建了一个“服务器”文件，将旁路配置添加到其中，突然在服务模式下CruiseControl.NET和Subversion可以看到远程存储库。
我仍然不完全确定为什么它在命令行模式下运行但不是服务模式，但我已修复它所以我很高兴。 ：）