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

评论

35 楼 noble 2007-03-19  

除非有人接过CVS的大旗，继续开发；否则，被SVN或其它什么的替代是迟早的。

34 楼 yuxie 2007-03-19  

robbin 写道

1、速度慢，不是一般的慢，严重打击项目团队代码同步积极性，其后果就是整个项目代码失控

一个代码量比较庞大的项目，开发活跃，提交频繁，SVN库的同步速度会越来越慢。06年我参与进入的一个项目，代码量很庞大，svn同步一次需要5分钟左右，导致整个项目团队的svn同步积极性很低，代码冲突，版本冲突时有发生，搞到后来大家都很害怕update，生怕自己的代码更新以后不能运行了。

我们的代码加起来53MB,用SVN同步一次一般不超过10秒。反而以前用cvs的时候出现过很慢的情况。~

33 楼 duduwolf 2007-03-18  

哦，对了，如果觉得svn的repo膨胀的太快，可以试试在你的cvs中定期加上分支，看看最终是谁胀得快，我觉得应该在支持原子级commit的svn中取消tag功能了。

32 楼 duduwolf 2007-03-18  

cvs和svn设计的初衷是用来存储源代码的，不是拿来当项目管理备份的，可以看看配置管理方面的书，如果你要保存的内容动辄上G，建议用商业的配置管理软件，比如Harvest等。
楼主认为的svn的缺点，在我认为恰恰都是好处：代码库不透明，提高了安全性；无法彻底删除文件更因该是好事啊，按道理就因该每一次动作所导致的结果都应该有迹可寻。
至于说svn比cvs慢，在我这里却是恰恰相反，或许我用的是cvsnt的缘故吧，svn比cvs快很多

31 楼 dada 2007-03-18  

robbin 写道

2、Eclipse的subclipse的插件有bug
只要用过，这个是大家都知道的，不多说了。反正很影响团队提交代码的士气。

这点很致命，曾经在项目初级遇到几个无法提交的bug以后，严重影响了对svn的信心。
哪怕就是现在也时不时地来几次bug，需要手工修改entries才能提交。

30 楼 robbin 2007-03-18  

Wuvist 写道

如果我没有记错的话……

svn默认是使用berkeley DB做为项目存储……慢还是一回事……它还会时不时崩溃……

不过，svn现在已经推荐使用fsfs作为存储……稳定＋快：
http://web.mit.edu/ghudson/info/fsfs

我就是用fsfs方式，对速度非常非常不满。

29 楼 sean_gao 2007-03-18  

不知道你是不是在实际操作中使用过SVN的dump和svndumpfilter，正常一个完整备份直接tar cz整个资源库目录即可，但是如果想做svndumpfilter，必须要完整dump到一个文件，然后pipe到svndumpfilter命令，这个命令目前并不支持wildcast，且直接在dump出来的*文本*文件上过滤，直接这样用是要冒风险的，因为你没有一个test case可以保证这样做以后没有动到不该动的文件。

在一个实际的案例中，我的资源库大约在1.2G，checkout出来有3G，dump一下，用一个文件存起来就是3个多G，再svndumpfilter把这个文件作为输入，然后再load回来？生产环境我可不敢随便这么弄。而且这个过程是不是要freeze掉整个库呢？

你提到的暂时建一个临时库，日后再merge，但revision版本号可能在很多地方都会被引用到，比如你的issue-tracking，不是随便可以改的哦。

引用

库臃肿通常不是问题，大硬盘现在谁都买得起。处理一次要几个小时甚至一整天才是大问题。项目中最耗时的一般是编译、测试和发布的步骤，而文档和这些步骤无关，再大也没关系。

我们说的是一个意思，我说臃肿的资源库的问题，其实隐含了对它进行处理的overhead。至于文档的话，会影响到日常的备份啊，哪怕你是用增量备份的方式。

正如你所说，很多东西我们没得选，比如有时候你的客户，尽管他对技术知之甚少，他也完全可能对你采用的技术平台/框架有话语权甚至决定权。但是当你有的选的时候，也应该充分利用这个机会。况且我们讨论半天，其实还是在可以选择的前提下，不然还有什么可谈的余地？

我想我对SVN的意见基本还是客观的，基于技术层面的考虑，对有些SVN爱好者言论的不满，可能更多的体现在后面的一系列讨论中。先有对SVN的意见，再有对SVN爱好者的意见，我想应该是这个顺序。

28 楼 treenode 2007-03-17  

robbin 写道

其他的好处，没有了。很多人说SVN支持改名重命名情况下保留了提交记录，对不起，我用CVS这么多年，从来没有感受到通过Eclipse重构以后，在查看提交记录方面遇到困扰。

Eclipse的确弥补了CVS本身的一些不足，wincvs和其他的一些用户可就没这么好运气了。

27 楼 treenode 2007-03-17  

引用

没有谁让任何人无休止的出错，但是每个人都有犯错的可能，每次犯错也都有文件大小比较离谱的可能，每次犯错也都有敏感文件被上传的可能，每次这种错误出现，都增加了管理成本和资源浪费。团队较小且集中时，可能还好，团队大了，甚至分布式了，纠正错误而不影响到版本历史数据完整性的难度是很大的。

.............
我每次上街都可能被汽车撞死，每次坐电梯都可能碰上事故，每次上班都可能遇到火灾，每次吃饭都可能吃到毒素，那么我现在还活的好好的究竟是为什么呢？
拿极端的情况当每次都发生的问题就没意思了，何况你已经知道在这种极端情况下svn也有解决的办法。

引用

有人喜欢SVN，有人喜欢CVS。赖不赖账是一回事，提不提供某个管理选项是另一回事。

你都知道了svn有dumpfilter可以解决这个问题了不是么？就是过程比较麻烦罢了，为什么还老是强调人家没给你这个选项啊？

引用

可能我们理解的接口/实现不尽相同，拿CVS来举例，CVS存储文件的格式定下来形成文档以后就是接口规范，实现是具体的CVS服务端软件，接口应该是相对稳定的，而实现可以是Unix/Linux/BSD下的各个版本的CVS（1.1/1.2/1.12.9），也可以是Windows平台的 CVSNT，而当你升级CVS版本或者平台移植时，只要把整个目录打包拷贝解压即可。CVS存储是按照实际文件组织结构存放的文本文件，不存在什么存储实现的问题，用户拥有对数据的最终的控制权。在这一点上CVS更符合Unix的哲学，还是那句话，Unix is not for everyone.

看来你我的理解的确不太一样。
不管你用CVS还是SVN，都应该是通过系统提供的命令接口去操作的，CVS也不会鼓励你hack到文件系统里面去手工删除一个文件。版本系统的存储实现不透明到底会给你带来什么问题呢？

引用

存储别人已经做好打包好的文件和提供相对更加动态的资源库是两码事，而且我前面也已经说过，文件大小并不仅仅影响到占用多大硬盘。

把自动化脚本写好，定时任务配置好，接下来就可以去喝茶了，文件大小的确不是问题，不然你为什么还要特意强调超大型文件和占用资源？删除一个无用的文件要占用你什么资源呢？

引用

假如你所在的是一个分布式的团队，分别在上海、大阪、新加坡的分部，以及在北京的用户现场，而通常这样的团队不可能有专人24小时管理资源库，结果大阪有一个组员不小心上传了错误的文件（可能是他的整个私人收藏目录），新加坡组员随后上传了重要的底层框架补丁，而北京现场正在分秒必争的在完成一些重要的客户化，需要保证随时能够访问资源库，提交客户化代码和构建新的版本作发布使用，当管理资源库的上海分部管理员收到大阪团队的E-mail要求在严格保密的前提下安全的在下一次自动备份前删掉误上传的文件时，版本号已经翻新了不知道多少回。这个时候怎么办？谁去收拾这个烂摊子？面对各方压力，谁来保证第一时间解决问题？

你说的这种情况，版本号更新多少都不是问题，因为大阪成员当然知道自己是在哪个版本上传的文件。只有北京需要即时访问这一点有些困难。暂时想到一个办法：1、将大阪的文件删除后马上做个标记；2、仅将这个版本导出到一个新的库，规定后续工作都必须从这个库开始，然后原先的库撤下；3、在原来的库里彻底删除文件，等代码稳定后再和新的库合并。

引用

对于单纯的源代码的管理，一般来说200M就算是比较大的项目了，使用的人员相对比较单一，文件类型也相对固定。但是管理文档的话，用户、文件数量、文件类型和资源库大小就没那么好控制了，所以采用好一些的项目组织方案也未必能够解决臃肿的资源库的问题。

库臃肿通常不是问题，大硬盘现在谁都买得起。处理一次要几个小时甚至一整天才是大问题。项目中最耗时的一般是编译、测试和发布的步骤，而文档和这些步骤无关，再大也没关系。

引用

说了这么多，我都不知道自己在捍卫什么了

从前面你的发言我就有点感觉到，大概你是对某些SVN爱好者有些看不过眼，连带着对SVN也有意见了。其实技术就是技术，没有这个必要。SVN不是没有缺点，慢的问题我也经常能感受到，不过sourceforge上面那么多项目，有的只提供cvs访问，有的则只提供svn，这时你是没有什么选择的，捍卫没有用，两手准备才行。

26 楼 robbin 2007-03-17  

我是一个对新技术持有非常拥护态度，而且勇于尝试新技术的人。svn对我来说，比CVS的好处有二：

1、支持创建空目录
CVS不支持空目录，这对于Java来说一般没有什么问题，但是对于RoR，这点比较讨厌，当然我现在都是在空目录下面创建一个readme文件解决问题。

2、每次提交都是整个repository的一个version
这样便于跟踪整个repository的状态，不像CVS是针对单个文件的version。当然像有cvstrac这样的工具，也提供了很多弥补。

其他的好处，没有了。很多人说SVN支持改名重命名情况下保留了提交记录，对不起，我用CVS这么多年，从来没有感受到通过Eclipse重构以后，在查看提交记录方面遇到困扰。

基本上SVN给我带来的我需要的好处，在我使用cvs的情况下自己也可以克服，但是SVN带来的缺点我就很难忍受了：

1、速度慢，不是一般的慢，严重打击项目团队代码同步积极性，其后果就是整个项目代码失控

一个代码量比较庞大的项目，开发活跃，提交频繁，SVN库的同步速度会越来越慢。06年我参与进入的一个项目，代码量很庞大，svn同步一次需要5分钟左右，导致整个项目团队的svn同步积极性很低，代码冲突，版本冲突时有发生，搞到后来大家都很害怕update，生怕自己的代码更新以后不能运行了。

之后我把代码库迁移到Linux+reiserfs+cvs上面，代码库同步一次5秒种完成，该代码库经过3个月开发和不断提交，同步一次也从来不超过10秒种。

后来我想当时可能因为svn在是windows上面走了http，于是自己亲自操刀在Linux上面配置svn server，走svn协议，再把整个代码库挪过来。然后同步一次，至少30秒种，放弃之。

最后补充一句：我从来不用CVSNT的原因也是它速度慢，实在太慢，项目一大，就影响项目团队的代码提交积极性。

2、Eclipse的subclipse的插件有bug
只要用过，这个是大家都知道的，不多说了。反正很影响团队提交代码的士气。

06年我用过三次svn，第一次不是我安装的，后面两次都是我主动尝试，最长时间坚持了一个月，实在坚持不下来，迁移回到CVS。

25 楼 sean_gao 2007-03-17  

http://blog.zenspider.com/archives/2007/03/what_the_hell_is_wrong_with_subversion.html

刚看到的，也许可以佐证robbin前面提到的第一点。

24 楼 sean_gao 2007-03-17  

引用

这就有点欲加之罪了。你上传错误文件，一次两次可以，谁让你无休止的出错了？

没有谁让任何人无休止的出错，但是每个人都有犯错的可能，每次犯错也都有文件大小比较离谱的可能，每次犯错也都有敏感文件被上传的可能，每次这种错误出现，都增加了管理成本和资源浪费。团队较小且集中时，可能还好，团队大了，甚至分布式了，纠正错误而不影响到版本历史数据完整性的难度是很大的。

引用

SVN的哲学是作为版本控制系统就应该忠实的记录历史。不管你出错还是什么原因，作了就是作了，你不能简单的一个命令上来就赖账说我没有做过。

有人喜欢SVN，有人喜欢CVS。赖不赖账是一回事，提不提供某个管理选项是另一回事。

引用

存储方式不透明是好事，这样SVN以后修改存储实现也不会威胁到用户的现有数据，为什么会成为缺点呢？我们不是一直提倡要针对接口而不是针对实现吗？

可能我们理解的接口/实现不尽相同，拿CVS来举例，CVS存储文件的格式定下来形成文档以后就是接口规范，实现是具体的CVS服务端软件，接口应该是相对稳定的，而实现可以是Unix/Linux/BSD下的各个版本的CVS（1.1/1.2/1.12.9），也可以是Windows平台的CVSNT，而当你升级CVS版本或者平台移植时，只要把整个目录打包拷贝解压即可。CVS存储是按照实际文件组织结构存放的文本文件，不存在什么存储实现的问题，用户拥有对数据的最终的控制权。在这一点上CVS更符合Unix的哲学，还是那句话，Unix is not for everyone.

引用

我不知道几G的文件会成为多大的负担，平时下载Linux ISO和微软CTP，这些文件也都动辄4、5个G，也没什么不敢想象的呀。

存储别人已经做好打包好的文件和提供相对更加动态的资源库是两码事，而且我前面也已经说过，文件大小并不仅仅影响到占用多大硬盘。

引用

再说，发现错误就应该第一时间处理。如果你们不早点发现问题，而是等空间长到上G的时候才来解决，那到底是谁的问题呢？

假如你所在的是一个分布式的团队，分别在上海、大阪、新加坡的分部，以及在北京的用户现场，而通常这样的团队不可能有专人24小时管理资源库，结果大阪有一个组员不小心上传了错误的文件（可能是他的整个私人收藏目录），新加坡组员随后上传了重要的底层框架补丁，而北京现场正在分秒必争的在完成一些重要的客户化，需要保证随时能够访问资源库，提交客户化代码和构建新的版本作发布使用，当管理资源库的上海分部管理员收到大阪团队的E-mail要求在严格保密的前提下安全的在下一次自动备份前删掉误上传的文件时，版本号已经翻新了不知道多少回。这个时候怎么办？谁去收拾这个烂摊子？面对各方压力，谁来保证第一时间解决问题？

引用

还有就是，大项目最好划分成小项目。把所有东西统统堆到一起只是图最初的方便，以后涨到几万个文件、占用上G空间、处理一遍几个小时，谁都受不了。我自己也受过这种苦，所以我建议你们无论如何应该慎重考虑一下项目组织的方式。

谢谢你的提醒，不过我的看法是这样：

对于单纯的源代码的管理，一般来说200M就算是比较大的项目了，使用的人员相对比较单一，文件类型也相对固定。但是管理文档的话，用户、文件数量、文件类型和资源库大小就没那么好控制了，所以采用好一些的项目组织方案也未必能够解决臃肿的资源库的问题。


P.S.
说了这么多，我都不知道自己在捍卫什么了，本来就是记录一下这个过程以及过程中遇到的一些问题和想法，没想到引来大家的如此关注。不过把问题谈开了，也算是为大家提供一些有价值的信息和思路。Subversion的粉丝们大可继续使用你们的Subversion，不知道如何选择的朋友也大可以多听听大侠们介绍Subversion的优点，不过我还是坚持我的判断和选择。

23 楼 treenode 2007-03-17  

引用

2- 资源库几乎是以一种完全不透明的方式存储用户资源库文件;

存储方式不透明是好事，这样SVN以后修改存储实现也不会威胁到用户的现有数据，为什么会成为缺点呢？我们不是一直提倡要针对接口而不是针对实现吗？

引用

对于最后一条，官方说法是提供了一个svndumpfilter的方式，先把资源库dump出来，然后pipe到svndumpfilter过滤掉匹配的文件，最后再load回去。这几乎就是给我们判了死刑：dump文件动辄就会是好几个G，且随着时间增长，或者错误提交持续出现在超大型文件上，要完成这个dump和filter，以及周期性的备份，将要吃掉多少资源，不敢想象；svndumpfilter不支持wildcast，且这个字符串匹配由于是整个dump文件pipe到svndumpfilter，无法保证精确制导，尤其在生产环境，敏感文件被上传、有效文件被误删或者资源库遭到破坏的后果是很严重滴。

我不知道几G的文件会成为多大的负担，平时下载Linux ISO和微软CTP，这些文件也都动辄4、5个G，也没什么不敢想象的呀。

再说，发现错误就应该第一时间处理。如果你们不早点发现问题，而是等空间长到上G的时候才来解决，那到底是谁的问题呢？还有就是，大项目最好划分成小项目。把所有东西统统堆到一起只是图最初的方便，以后涨到几万个文件、占用上G空间、处理一遍几个小时，谁都受不了。我自己也受过这种苦，所以我建议你们无论如何应该慎重考虑一下项目组织的方式。

22 楼 treenode 2007-03-17  

sean_gao 写道

其实不止是多占点硬盘空间啊，单纯说资源占用的话，还应该算上正常使用和备份所额外占据的CPU、带宽、硬盘、光盘/磁带、管理成本，都是需要考虑的。一个完整的备份不能无休止的膨胀吧？也许有人觉得永远不删除上传过的文件是一个优点，那么时间久了，那么多垃圾扔在上面，会不会影响正常的访问性能呢？我宁愿相信它会，因为服务器的软硬件资源总是有限的。

这就有点欲加之罪了。你上传错误文件，一次两次可以，谁让你无休止的出错了？

SVN的哲学是作为版本控制系统就应该忠实的记录历史。不管你出错还是什么原因，作了就是作了，你不能简单的一个命令上来就赖账说我没有做过。

占用空间大小的问题前面已经有人证实过，我这边的结果一样，22.5k。不知道几十兆的数据是哪里来的，你还是最好自己检查一下。

速度问题，我遇到过用subeclipse里面处理文件太多的时候将近半个小时没有反应的情况。后来换用TortoiseSVN几分钟就完成了，可见不同客户端的差距还是相当大的。

如果说SVN有什么必须用的理由的话，那我想第一条应该是：重构。在Java里面类名的修改同时也改变了文件名，而CVS不支持保存文件重命名的历史记录，这样重构信息就丢失了。SVN则没有这个问题。

21 楼 jerry 2007-03-17  

SVN有好处还是多的，如果你在使用RADRAILS你发现SVN的插件提示的更好，你可以看到文件是谁最后一次提交的，版本是多少，同时SVN是原子操作的，所以速度确实也是慢。不过我感觉如果只是浏览时显示信息多这一点就非常不错了。

20 楼 sean_gao 2007-03-16  

江南白衣 写道

hehe，我的意思也是说，既然你认为无法删除失效文件，占硬盘是主要缺点，但Subversion有这么多好处，和多占了几块钱硬盘的缺点比起来，可以接受阿。

其实不止是多占点硬盘空间啊，单纯说资源占用的话，还应该算上正常使用和备份所额外占据的CPU、带宽、硬盘、光盘/磁带、管理成本，都是需要考虑的。一个完整的备份不能无休止的膨胀吧？也许有人觉得永远不删除上传过的文件是一个优点，那么时间久了，那么多垃圾扔在上面，会不会影响正常的访问性能呢？我宁愿相信它会，因为服务器的软硬件资源总是有限的。

另外不知道各位考虑过没有，如果有个committer不小心上传了敏感文件，于私可能是私密信函、私密图片，于公可能是公司机密、项目机密、可能会成为呈堂证供的证据。多人使用的资源库很容易被滥用，而一旦有什么状况发生，尤其当这个资源库被不同的团队使用，总应该提供一个安全合理的方式规避一些不必要发生的问题和纠纷吧？

可能有些人已经离不开SVN的某个特性或者某些特性，但是对我们来说，CVS足够稳定，也足够满足基本需要，要让我们放心转到SVN，还需要它的那套哲学和提供的功能更有说服力才行。

19 楼 江南白衣 2007-03-16  

hehe，我的意思也是说，既然你认为无法删除失效文件，占硬盘是主要缺点，但Subversion有这么多好处，和多占了几块钱硬盘的缺点比起来，可以接受阿。

18 楼 sean_gao 2007-03-16  

江南白衣 写道

但为什么不说一下Subversion的好处呢，相比起来，3G硬盘也就几块钱阿（200G的硬盘现在什么价了？）。

我已经在首贴作了说明：

引用

Subversion的优点就不在这里重复了，网上很多介绍文章，也有很多忠实粉丝

如果哪位感兴趣且有时间，不妨把你所知道的Subversion的优点都列举在此。

当团队较小开发地点也比较集中的话，怎么玩儿都可以。CVS不是给所有人玩儿的，Subversion当然也不例外，看各自的实际需求和喜好吧。只是有些反感Subversion的fanboi们有时候会在没搞清楚事情真相的情况下就对别人（不说Subversion好话的人）的判断和喜好妄加揣测和批评，这是对别人尊重的方式么？前面言语可能有些过激，如果给各位带来不愉快，还请多多包涵。

17 楼 江南白衣 2007-03-16  

但为什么不说一下Subversion的好处呢，相比起来，3G硬盘也就几块钱阿（200G的硬盘现在什么价了？）。

16 楼 sean_gao 2007-03-16  

李超群 写道

首先第一个问题，我新建一个repository,大小是22.5k.我们一个已经基本完成的rails的项目，目前repository大小是8.9M.

第二，subversion使用bdb做数据存储，是没办法直接看到。但是为了更快的访问。仔细看一下bdb的资料，访问起来应该不难。

第三，如果使用命令行，在commit之前一定要做的事就是status看一下目前所有添加的文件。同时Commit时添加message信息。如果确实是有误添加的情况（这种情况应该尽量避免），delete再commit或者直接用eclipse的插件在repository里删。

我看到很多人使用Subversion时跟cvs一样。直接在某个文件上点击提交。subversion的revision是用于repository的而不是用于File的。所以正确的使用方式很重要。

因为Subversion的方式，我们基本上不需要tag功能。所以从长久来看，肯定要比cvs的文件占用小得多。

delete再commit? 你确定这样能够真正删掉一个已经提交到资源库的文件？