nginx 和 subversion

实在厌倦了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程序。这是这篇博客的地址,有志于自己动手解决这个问题的人,可以参考一下:)

nginx 和 subversion》有4个想法

  1. Sam

    其实我也遇到了。。我想到apache每次产生会话都要占用一定客观的资源。如果用nginx直接转发到svn上去。在服务器上建立一套生产环境和运行环境。就不会对服务器带来太大的性能损失。而实际上现在的情况,如果公司里20个人连在一台服务器上去。。。最少会产生20个连接。。我觉得这个没必要。。。
    另外。。每次修改文件的时候。。。为什么会知道我修改了呢?我个人猜测是到服务器上对比一下。。。不知道是不是这样。。。
    但是,我还有一个疑问。。。如果nginx+apache+svn。。。这个不等于还是要产生这么多的连接么。。

    回复
  2. sunbo

    最后感叹一下,为什么计算机方面的问题,总是能在国外的网站和MaillingList找到答案呢?是中国人都不会么?还是这些问题只有我这一个中国人遇到了?

    我也有这个感叹 呵呵

    回复
  3. Kenn

    最终还是采取了proxy的办法,把发向nginx的svn请求转到apache上去了

    请问这样性能要比单独用apache好吗?

    回复

kevin进行回复 取消回复

邮箱地址不会被公开。 必填项已用*标注