驱散对Subversion的FUD

【IT168 分析评论】    本文是Ben Collins-Sussman针对关于Subversion的一些非议写的一篇文章,其中FUD的意思是“恐惧,不确定性和疑义”。

    我是Subversion项目最初的开发者,这是我写的一篇非常个人化的文章,我不会装出丝毫的客观,只是代表了个人的观点和对Subversion的感觉,这不是一篇官方的项目文档,只是希望人们会在他们看到关于Subversion的FUD时,能够链接这篇文档。我的目标是驱散在网上流传的许多流言和误解。
    在开始之前,需要给小心的管理员一点忠告。如果你正在学习Subversion,并且想在团队或者公司里使用,请你像使用普通的新产品一样使用Subversion。这并不是说Subversion不可靠,只是意味着不应该使用任何常识。不要没有任何测试的盲目跳入,没有任何用户希望新产品强迫他们。如果你是负责系统管理工作,你必须在推广给别人之前对它足够熟悉。找一个小项目,作为Subversion的试验,寻求热情的志愿者来进行试验,最后,如果Subversion有好的结果,你会有许多高兴的开发者(从一开始参与这个过程),你也可以开始准备大的设置。
    就这样了,下面是我最常听到的FUD。

    Subversion非常难于编译,有太多的依赖,我听说它需要Apache……打断一下!

    首先说一下Apache的问题。Subversion不需要Apache,它依赖Apache Portable Runtime(APR)库,并不等同于Apache的Web服务器。APR允许Subversion客户端和服务器能够在Apache存在的任何地方编译,同一个道理,Netscape Portable Runtime(NSPR)让Mozilla可以在任何地方编译。
    Subversion有两种不同的服务器:你可以使用包含WebDAV模块的Apache2,或者是使用类似于CVS pserver的独立运行的“svnserve”服务器。没有一种Server会是“更官方的”,两种方式都存在一些代价,可以看看Subversion Book的第六章中的一些特性比较。
    第二,关于“难于编译”的问题。你最后一次编译CVS是什么时候?从来没有?那是因为它安装在每一个系统,对吧?如果你使用支持良好的操作系统,Subversion二进制一定是你的发布版本(rpms、debs、fink等)的预装标准包,或者非常容易下载(Win32的情况)。
    编译是开发者的事情,不是用户的。Mozilla、Evolution、KDE和Gnome也都有许多过度的依赖,但是大多数用户不知道也不关心,因为他们并不编译。事实上,Subversion有这么多依赖是因为它有很多复杂的特性,并没有重新发明轮子,没有不寻常的东西。

    Subversion没有打破所有的根基——它保存了CVS的模型,为什么都要模仿CVS?

    从一开始,Subversion项目一直有一个“基本公理”:CVS是版本控制一个已证明的完美模型;它只是没有能足够好的实现。
    我们不是打磨垃圾,我们是在打磨粗糙的钻石。Subversion采纳了CVS模型,添加了版本控制、原子提交、数据库后端、版本化的元数据、有效地二进制处理、灵活的网络能力和坚实的C API,大多数特性是CVS应该首先具备的特性。
    如果你不认可本项目的基础公理,就没有必要多说了,你不适合Subversion。
    一些新的竞争的版本控制系统是“分布式的”或“非集中式的”——例如Monotone或Arch,甚至非自由系统,例如Bitkeeper。这些产品提供了工作的新方式,每一个开发者都有一个私有的版本库,版本库可以以任何等级的方式交换变更。
    许多Subversion开发者对这些分布式系统有复杂的感觉,一方面,这听起来很整洁,我们很有兴趣尝试一下;另一方面,许多用户抱怨这些东西有多难使用,或许有些会随时间得到改善。但是至少一个Subversion开发者相信,非集中式的模型对于自由软件开发是不恰当的。你要自己作出选择。
    此刻,还没有将Subversion变成非集中系统的完整计划,但是有一个基于Subversion库的有趣的非集中项目svk,它应该可以与普通的Subversion版本库和不使用svk的普通用户是共存。许多人真的喜欢它,所以你可能会将其检出。Subversion项目,最起码,计划会有一天学习svk,只是去看一看如何实现各种各样“智能合并”。谁知道呢?也许一些非集中能力也会融入Subversion,一切在此刻都还只是构思。

    如果Subversion只是“CVS的改进”,为什么花了四年才进入1.0?在CVS基础上增加一些特性就这么难吗?

    请不要因为我们仅仅“扩展了CVS的一些特性”就侮辱我们的项目,这些特性不能通过扩展CVS实现。CVS的代码基佷混乱,非常难于扩展(尽管如此,仍然有两个项目尝试如此:CVSNT和MetaCVS),这就是我们从头开始重新设计的原因。Subversion和CVS没有共同的代码;它们之间共同点只有并行、集中式的模型和相似的UI。
    我们通过实现管理工作拷贝数据和理解版本化目录的日志库开始,然后我们在事务性数据库基础上实现了一个版本库,每一个事务储存整个目录树,花了14个月实现了使用Subversion保存自己的代码。之后,大约花了两年半时间持续的使之稳定,发现bug和回归测试,每几个周就发布一个新的版本,目录树的版本化是一件困难的事情。
    当Subversion进入了“alpha”阶段,它已经经过了几十位开发者和工作室的实际工作的考验。此刻,任何其他项目都会叫这个产品“1.0”,但是我们决定尽可能延迟这个标签,因为我们是管理用户不可替代的数据,所以我们在标注1.0这件事上非常保守。我们已经意识到许多人在使用Subversion之前在等待这个标签,对这个标签的含义充满了期待,所以我们遵守这个标准,数据丢失会摧毁一个SCM的名誉。

    我为我们的公司研究不同的SCM解决方案,我有一个Subversion与其他系统的比较表格,我认为Subversion缺少了[特性 X],你不认为这是一个问题?有计划解决这个问题吗?为什么会希望团队为这个项目贡献,但是最终不会看到这个特性的实现。

    首先,威胁没有任何结果,许多人以为可以通过提供资源影响项目,但是如果使用这些资源意味着将项目引入错误的方向。Subversion像其他开源项目一样,是基于代码贡献和讨论的知识精华。欢迎你和其他人一起参与进来,但是必须遵守共同的术语和规则,更多细节请看HACKING文档。
    第二,Subversion的开发者确实知道特性蔓延问题,许多项目有松散的目标,对所作的事情没有坚实的定义,所以项目的范围不断扩大,社区不断变迁,不会发布任何东西,就像许多Sourceforge上的遗嘱一样的项目。从第一天起,我们的开发者就发表了一份简要的定义,说明了CVS的问题,和Subversion1.0将要做的和不会做的事情。如果你错过了讨论,很抱歉,那是网站的首页,是我们多年不变的指导。如果你希望影响1.0之后的特性,可以自由地加入到项目的讨论中来,并准备好写代码。一定要浏览一下我们的问题追踪和以前讨论的邮件列表,我几乎可以保证你不会是第一个询问这些问题的人。
    最后,我要讨伐许多在网上见到的SCM“比较表格”。真诚地讲,我有许多原因对这些东西保持不信任。许多编写者都是某个SCM系统的核心开发者,所有的讨论都是在作者自己系统的术语和方法论框架下进行的。另一方面,许多作者都是简单的信息收集者;表格读起来像书籍报告,你的印象就是作者读了所有项目的描述,然后简单的总结出来,但是作者缺乏甚至没有在团队中实际使用系统的经验。最后,我对这些表格之后的假设有我的个人异议,许多SCM特性被列出来好像有一个理想的、柏拉图似的系统,“让我们看看这些系统累加起来与完美系统的比较!”真是一派胡言,没有完美的系统,每一种系统都有优点和缺点,每一种系统在特定项目都有其优势和劣势,没有一种图表会告诉你那一种系统适合你,你需要自己去尝试。

    为什么Subversion没有使用好的现代语言,如Java或C++编写?为什么使用古老的C?

    这是一个危险的领域——没有人希望卷入这场语言圣战,我们使用C有一些原因,下面是我们开发者的解释:

  • 可移植性:C++编译器没有C语言编译器级别的标准,一种C++编译器可以执行的代码不能工作在另一种下,而C++库的链接更是一场恶梦。
  • C有大量熟练的程序员。
  • C库API可以几乎所有的其他语言访问,这对Java来说不是真实的。 

    可移植是这里的重点,因为Subversion是由C库编写并不意味着你必须使用C,有许多Subversion库的绑定,例如perl、python、Java和C++,都被许多第三方项目使用。

    数据库后端太危险也不友好,如果我希望修改数据结构呢?如果是CVS,至少我可以用编辑器打开RCS文件。

    你是暗示人们直接搞坏RCS文件更加安全?让我们把问题反过来:你为什么要将RCS文件载入编辑器?为什么你的管理员手工移动CVS版本库的文件?以我的经验,这通常因为CVS本身的问题和缺陷,一个好的系统应该避免版本库的修改。
    当你希望在网络上分享高度组织的数据,现在标准的实践是什么?佷简单,把数据放到数据库(如MySQL),然后通过Web界面展现,这是经典的LAMP方案。
    Subversion作了同样的事情:将你的数据存放在数据库,使之可以在网络上访问。请注意,没有人因为将关键数据存放在MySQL感到恐慌,而MySQL的数据不是能用编辑器直接修改的。如果你希望查看低层次的数据,必须使用导出工具;如果你希望移植数据,需要导出为一种可以移植的、透明的格式。
    还需要提一下,Subversion 1.1可以创建完全不使用BerkeleyDB的版本库。“fsfs”使用普通的OS文件保存数据。依然是二进制格式,还是意味着不可以人工编辑!)

    我的朋友说Subversion非常慢。

    是的,曾经是这样的,我们花了大量时间来解决正确性而不是速度。在2003年后期,我们也花了大量时间进行性能优化,通过我们自己的测试,Subversion 1.x的速度与CVS相近。

    看,Subversion不是butterflies和rainbows,如果出了问题我该怎么办?

    我不想欺骗你,Subversion依然有一些问题,但是我们只是希望在宇宙毁灭之前作一些感兴趣的事情,我们必须容忍不完美:

  • 许多错误信息应该被清理,我们正在努力。
  • 很容易得到字符转化失败。版本库使用UTF8保存所有的路径和提交信息,但是客户端可能一直不能转化UTF8为本地系统的设置,我们应该优雅地解决这种失败,在验证UTF8方面做得更好。
  • BerkeleyDB需要关心和照顾。一方面,它非常简单的提供了事务性数据库,而不是强迫用户创建完整的SQL系统。但是另一方面,许多人对于数据库恣意挥霍,如果访问版本库(apache、svnserve、svnadmin和svn等)的进程对于db文件没有完全的读写权限,数据库会锁住,并且需要日志恢复到一致的状态,这不是佷严重的问题,但这通常会使不够小心的人无所适从。“更大的力量带来更大的责任”——大多数人没有意识到这种责任,并且得到了失败,因为他们像对待CVS版本库一样对待SVN版本库。请阅读本书的这一小节,你将成为“受过教育的用户”。
  • 作为选择,创建“fsfs”版本库而不是BerkeleyDB的——没有数据库的问题,并且可以工作在NFS,见Subversion 1.1的发布说明。

转载请注明:皇冠顶尖高手论坛_乖乖彩色图库 » 驱散对Subversion的FUD

发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址