作为一个长期的潜伏者，我弹出了一个棘手的关于CruiseControl.NET，Subversion和远程存储库的问题。问题如下：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;然而，这只是让人感到不满意，因为我们更喜欢在服务模式下运行它（这对我们本地域中的存储库来说工作正常），以避免创建计划任务以在机器启动时启动它的必要性。
任何人有任何建议吗？