刚才见面，就说再见: 小记Subversion试用心得
由于工作需要，最近在Linux服务器上试用Subversion，如果一切顺利，全公司的文档都将交给Subversion管理。我承认我对Subversion一直存在偏见，但为了给大家一个交代，还是硬着头皮小试了一下。结果运行数天以后，终于还是回到了CVS的老路上。
Subversion的优点就不在这里重复了，网上很多介绍文章，也有很多忠实粉丝，不过没办法，我还是更喜欢CVS的简单和直接。熟悉Unix和类Unix系统的朋友一定有同感，CVS更加符合Unix的思维和解决问题的方式。
让我们最终放弃Subversion主要有以下大大小小的原因：
1- 一个新建的几乎是空的资源库，打包后大小即有39MB上下; << 经核实错怪SVN了，实测完全空白的资源库124K，向大家道歉！
2- 资源库几乎是以一种完全不透明的方式存储用户资源库文件;
3- 没有一个官方的、安全可靠的方式彻底删除一个误提交的文件，一旦提交上去，你的资源库将永远背着这个包袱; << 这一条实在让我无法忍受。
对于最后一条，官方说法是提供了一个svndumpfilter的方式，先把资源库dump出来，然后pipe到svndumpfilter过滤掉匹配的文件，最后再load回去。这几乎就是给我们判了死刑：dump文件动辄就会是好几个G，且随着时间增长，或者错误提交持续出现在超大型文件上，要完成这个dump和filter，以及周期性的备份，将要吃掉多少资源，不敢想象；svndumpfilter不支持wildcast，且这个字符串匹配由于是整个dump文件pipe到svndumpfilter，无法保证精确制导，尤其在生产环境，敏感文件被上传、有效文件被误删或者资源库遭到破坏的后果是很严重滴。
其实svn还是有不少优点的，比如svn switch直接支持repository的url修改，在cvs还是比较麻烦的事情 尤其对于repository不在本地的团队，我想svn和cvs更新一遍的速度不会差太多吧，网络才是瓶颈。
所有的东西都无法真正删除，这是好事还是坏事就说不清了，SVN好比数据仓库，CVS好比数据库，没法说哪个不好，只能说你需要哪个。楼主害怕在硬件上破费，可也有不在乎这点开销的。如楼上所说，类似sourceforge.net/kde.org弃cvs用svn的做法，不是没道理的。
另外对于那句反复出现的Unix is not for everyone有点意见:) 其一这个似乎算不上UNIX的哲学。其二它的本意好像和语境也不太着边。
在这里看到关于SVN vs CVS性能的讨论, 比较感兴趣, 遂研究了一下.
我原来的印象是说 SVN 因为每提交新rev都是增量记录变动的数据, 所以要获得一个最新版的文件, 必须从最初的版本开始, 曾经的修改全部 "重做" 一遍. 如果是这样那么它慢的道理大概是在这里. 于是就想, 按这个道理在server上设置一个cache不就解决了? 每个rev对应的真实文件 "重做" 出来放在那里, 下次就可以直接用了, 进而避免每次 "重做" 的开销. 另一方面cache目录可以和repository目录分开, 这样备份的时候也只是备份增量数据, 不用保存那么多冗余内容. 似乎是个可行的性能解决方案.
但是查了 SVN-BOOK, 根本没有这种选项, 而且出乎意料的发现这段话:
好奇之下自己做了些实验, 用的是 Collabnet 的 SVN 1.4.2, FSFS. 发现它的repository文件格式还真是不太摸得透, 有的时候文本文件一点改动也会记录大片数据, 有的时候则不会, 这个也许是diff算法的原因. 不过可以肯定的是真正运行起来的结果根本不是像前面那段话描述的样子, 它还是记录新rev对老rev的delta, 而不是反过来. 所以性能问题的根源大概就在这里了.
仔细想想, SVN 提交的时候在 db/revs 下面是只写新文件的, 又怎么可能改老版本的delta数据呢. 这样看来, 上面 SVN-BOOK 里的描述纯粹是忽悠人啊; 而且除非它加一个针对各revision的cache机制, 否则性能问题在所难免了: 每次要求一个文件的时候都必须把历史更改 "重做" 一遍 - 小文件少改动还好, 大文件, 曾经多次修改过的资源, 岂不是要累死服务器的 CPU 和 硬盘 去做没必要的重复事情了. 51 楼 cookoo 2007-06-10 ozzzzzz 写道GIT这个东西我朋友用过，觉得很好，但是在现在的企业环境下不适合，主要是没有权限系统。
实际上我觉得现在cvs和svn包括cc等scm软件都太复杂，这主要是由于cm的理论基础太复杂了。如果这个时候能够对cm的基础概念进行研究，推出一个lean一些的概念来，然后在按照这个概念构建一个软件会好很多。
实际上作为程序员来说，用到的命令其实有checkin和check out就够了。而面对管理员来说就复杂的多了，当然入手点就在这里。
这些年出了好多非集中式（意思是没有客户端/服务器之分，p2p方式）的轻量级版本控制软件，如git, mercurial, darcs等。基本差别我觉得是集中式每个有权限comit的人可能会有意无意影响其他人，而非集中式每个人随便在本地branch comit，只有整合者（integrator）有权选择可信任的patch维护一个整合branch。所以虽然非集中式看似更松散，但管理者的权利更加集中。
mercurial已经被OpenSolaris项目选中，毕竟使用python更方便写扩展。虽然我个人更喜欢用darcs管理小项目或者干脆当多台机器和u盘/外置硬盘之间的同步工具，不过haskell毕竟知道的人很少，有点影响darcs的开发。mozilla小组有个夸张搞笑的version control system shootout以决定该用哪种，估计是Mercurial吧。
和数据库一样，版本控制系统的移植代价非常之高，新的软件在可用(GUI)和稳定之前仍然需要漫长的时间。同时svn也出现了svk那样的扩展支持离线操作。
52 楼 marine_chen 2007-06-11 我的项目配了Subversion，我用eclipse把工程提交上去，但是尚未找到在linux服务器上工程存储地方，不知道哪位朋友能帮助一下？ 53 楼 grandboy 2007-06-19 除了Subclipse插件有没有更好的插件, 这个插件我觉得真是不太好用, 还是我不太会的原因?
除了大家提的速度慢(尤其是同步简直是慢得不行)的问题. 我还有以下一些问题请教大家有没有好的解决方案.
1. Update他连Update了哪些文件都没有.(以前我没有很好的设置，设置一下就可以出来这个update的列表)
2. 改文件夹经常没有办法提交. 出现莫名的错误.
3. 好象也没有很方便的去比较以前两个版本的差异的方法.
请.
54 楼 carlosbdw 2007-07-23 为什么我这里的cvs慢的要命，同步一次至少15秒 55 楼 yuanhuiwu 2011-09-26 svn配置用web管理，手动配置确实麻烦。 http://www.iteye.com/topic/1114697
