刚才见面，就说再见: 小记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，无法保证精确制导，尤其在生产环境，敏感文件被上传、有效文件被误删或者资源库遭到破坏的后果是很严重滴。

我在06年尝试过两次使用svn，最后两次都换回到cvs来。svn的缺点除你上面提到的之外，还有就是：

1、速度慢，非常慢。我构建在Linux/reiserfs上的cvs server，不管多大的cvs repository，同步一次，从来不超过5秒种。svn server即使走svn协议，同步一次都至少好几十秒，至于走http协议，慢得就没谱了。

2、在本地保留修改备份，我都连接svn服务器了，你还给我保留，造成本地项目目录急剧膨胀，动辄几百MB的空间占用，项目开发的时候，文件导航速度明显变慢。

能告诉我CVS对WORD文档是怎么管理的呢？
我一般用CVS来对代码就行管理，但试过对WORD文档似乎不支持。研究了很久也没有搞定，郁闷

Subversion号称要革CVS的命，看来很多人都不买它的账啊，呵呵。

我们用的是svn协议，反正也不打算提供Web界面，就没有考虑HTTP，文件少的时候感觉还好，文件一多，速度明显变慢。

把.doc当作一般binary格式的文件，只是做版本控制的话，CVS没有问题的，我们一直在用。实在需要diff或查看修改历史，也可以通过Word自带的工具来做。

楼主能指点一下，源代码多大的时候，svn才慢么？
我用svn做过的都是小项目，没遇见过很慢的情况。

Subversion的性能跟机器配置也有关系的，只是大小在同样级别的资源库，Subversion要比CVS慢，对于较大的资源库，这种感觉更加明显。不过性能问题并不是最终让我们放弃Subversion的决定性因素，让我们最终放弃的是原帖提到的第三点。

作为参考，我们的源代码资源库有200M左右，文档资源库陆续加入文档后涨到3G（全部检出后的大小）。

sean_gao 写道：
请教楼主，svn delete命令不行吗？看文档好像是可以从资源库中直接删除的?

看不到不代表 不占地方

xin_wang 写道：

Subversion有意设计成所有提交过的文件都不会丢失，举例来说你新提交一个文件，版本号更新为123，然后本地删掉，再提交，版本号变成124，这样123版本检出包含你的那个文件，124版本检出后不包含。除非你强行破坏性的人为干预，只要别人指定要123版本，那么别人就能够取得你的这个看似已经删除的文件。

这后面不是在变魔术，Subversion资源库保存了所有提交过的文件及其所有历史版本。