实在厌倦了apache的臃肿，打算彻底投奔nginx的怀抱了。
编译，安装，迁移，一切都很顺利 ，最后一步在迁移svn的时候卡住了。
把nginx作为subversion的前端webserver居然目前没有解决方案……
搞了一个晚上，最终还是采取了proxy的办法，把发向nginx的svn请求转到apache上去了 ，哎。
为啥nginx没有这方面的解决方案，也大概查了个水落石出。因为这方面中文资料实在是少，让我费了颇多的周折，
现在就明明白白的说一下吧。
在nginx.net的Mailing list里，nginx的作者Igor Sysoev说了，支持SVN需要有三个东西
1) full WebDAV support,
2) DeltaV support,
3) SVN repo format support.
而在nginx里的NginxHttpDavModule，仅仅对以上三项中的第一项WebDAV有了初步的支持(目前来看Igor Sysoev并没有升级的想法)，对于几个高级的WebDAV操作（比如OPTIONS、PROPFIND）并不支持，而这些操作，恰恰是SVN所必须的。而剩下的两项，更是一点支持都没。
所以，就目前来说，想单纯的nginx+subversion，基本上是不可能的。
在刚开始研究这个问题的时候，并不知道除了WebDAV还必须要有其他两个东西。所以满世界找nginx上WebDAV的解决方案，以为搞定这个，就万事大吉了。别说，还真让我在一个老外的博客上给找着一个。这家伙的方法很巧妙，他依据WebDAV的RFC文档，将绝大多数NginxHttpDavModule不支持的操作用PHP代码实现了，并且通过nginx，把这些请求重定向到了PHP程序。这是这篇博客的地址，有志于自己动手解决这个问题的人，可以参考一下：）
其实我也遇到了。。我想到apache每次产生会话都要占用一定客观的资源。如果用nginx直接转发到svn上去。在服务器上建立一套生产环境和运行环境。就不会对服务器带来太大的性能损失。而实际上现在的情况，如果公司里20个人连在一台服务器上去。。。最少会产生20个连接。。我觉得这个没必要。。。
另外。。每次修改文件的时候。。。为什么会知道我修改了呢?我个人猜测是到服务器上对比一下。。。不知道是不是这样。。。
但是，我还有一个疑问。。。如果nginx+apache+svn。。。这个不等于还是要产生这么多的连接么。。
最后感叹一下，为什么计算机方面的问题，总是能在国外的网站和MaillingList找到答案呢？是中国人都不会么？还是这些问题只有我这一个中国人遇到了？
我也有这个感叹 呵呵
最终还是采取了proxy的办法，把发向nginx的svn请求转到apache上去了
请问这样性能要比单独用apache好吗？
@Kenn 因为当初这个nginx还要干别的事……