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

评论

55 楼 yuanhuiwu 2011-09-26  

svn配置用web管理，手动配置确实麻烦。 http://www.iteye.com/topic/1114697

54 楼 carlosbdw 2007-07-23  

为什么我这里的cvs慢的要命，同步一次至少15秒

53 楼 grandboy 2007-06-19  

除了Subclipse插件有没有更好的插件, 这个插件我觉得真是不太好用, 还是我不太会的原因?
除了大家提的速度慢(尤其是同步简直是慢得不行)的问题. 我还有以下一些问题请教大家有没有好的解决方案.
1. Update他连Update了哪些文件都没有.(以前我没有很好的设置，设置一下就可以出来这个update的列表)
2. 改文件夹经常没有办法提交. 出现莫名的错误.
3. 好象也没有很方便的去比较以前两个版本的差异的方法.

请.

52 楼 marine_chen 2007-06-11  

我的项目配了Subversion，我用eclipse把工程提交上去，但是尚未找到在linux服务器上工程存储地方，不知道哪位朋友能帮助一下？

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那样的扩展支持离线操作。

50 楼 歆渊 2007-06-06  

我也觉得SVN难以删除数据这个 "特性" 对包含敏感信息的商业环境是个不小的问题, 当然对普通项目特别是开源项目这个问题要轻微得多.

在这里看到关于SVN vs CVS性能的讨论, 比较感兴趣, 遂研究了一下.

我原来的印象是说 SVN 因为每提交新rev都是增量记录变动的数据, 所以要获得一个最新版的文件, 必须从最初的版本开始, 曾经的修改全部 "重做" 一遍. 如果是这样那么它慢的道理大概是在这里. 于是就想, 按这个道理在server上设置一个cache不就解决了? 每个rev对应的真实文件 "重做" 出来放在那里, 下次就可以直接用了, 进而避免每次 "重做" 的开销. 另一方面cache目录可以和repository目录分开, 这样备份的时候也只是备份增量数据, 不用保存那么多冗余内容. 似乎是个可行的性能解决方案.

但是查了 SVN-BOOK, 根本没有这种选项, 而且出乎意料的发现这段话:

引用

To keep the size of the repository as small as possible, Subversion uses deltification (or, “deltified storage”)
within the repository itself. Deltification involves encoding the representation of a chunk of data
as a collection of differences against some other chunk of data. If the two pieces of data are very similar,
this deltification results in storage savings for the deltified chunk—rather than taking up space equal to
the size of the original data, it only takes up enough space to say, “I look just like this other piece of data
over here, except for the following couple of changes”. Specifically, each time a new version of a file is
committed to the repository, Subversion encodes the previous version (actually, several previous versions)
as a delta against the new version. The result is...

要是这么说, 倒是最新版本在repository里保存着完备数据, 历史版本是 "重做" 出来的了. 如果真是这样怎么会有那么大的性能问题呢?

好奇之下自己做了些实验, 用的是 Collabnet 的 SVN 1.4.2, FSFS. 发现它的repository文件格式还真是不太摸得透, 有的时候文本文件一点改动也会记录大片数据, 有的时候则不会, 这个也许是diff算法的原因. 不过可以肯定的是真正运行起来的结果根本不是像前面那段话描述的样子, 它还是记录新rev对老rev的delta, 而不是反过来. 所以性能问题的根源大概就在这里了.

仔细想想, SVN 提交的时候在 db/revs 下面是只写新文件的, 又怎么可能改老版本的delta数据呢. 这样看来, 上面 SVN-BOOK 里的描述纯粹是忽悠人啊; 而且除非它加一个针对各revision的cache机制, 否则性能问题在所难免了: 每次要求一个文件的时候都必须把历史更改 "重做" 一遍 - 小文件少改动还好, 大文件, 曾经多次修改过的资源, 岂不是要累死服务器的 CPU 和 硬盘 去做没必要的重复事情了.

49 楼 iunknown 2007-06-05  

<br/>
<strong>sean_gao 写道：</strong><br/>
<div class='quote_div'><br/>
Subversion的优点就不在这里重复了，网上很多介绍文章，也有很多忠实粉丝，不过没办法，我还是更喜欢CVS的简单和直接。熟悉Unix和类Unix系统的朋友一定有同感，CVS更加符合Unix的思维和解决问题的方式。<br/>
让我们最终放弃Subversion主要有以下大大小小的原因：<br/>
1- 一个新建的几乎是空的资源库，打包后大小即有39MB上下; &lt;&lt; 经核实错怪SVN了，实测完全空白的资源库124K，向大家道歉！<br/>
2- 资源库几乎是以一种完全不透明的方式存储用户资源库文件;<br/>
3- 没有一个官方的、安全可靠的方式彻底删除一个误提交的文件，一旦提交上去，你的资源库将永远背着这个包袱; &lt;&lt; 这一条实在让我无法忍受。<br/>
<br/>
<br/>
不是有 FSFS 吗？<br/>
<a href='http://svn.collab.net/repos/svn/trunk/notes/fsfs'> http://svn.collab.net/repos/svn/trunk/notes/fsfs</a><br/>
</div>
<br/>
<br/>

48 楼 cqwonder 2007-03-22  

这实际是一个投入与资产的问题.

cvs有cvs的问题, svn有svn的问题, 楼主cvs用得早,cvs的缺点都想办法克服了,而svn基本没用过,所以问题自然就大了.

楼主遇到的(第3个)问题主要是心理上的障碍,非要把心理障碍证明为生理障碍,所举的例子稍显极端且无理. 就好像我本人对硬盘中的垃圾文件的态度一样,不删它总觉心里不爽,但其实删不删很多情况下也是无所谓的,或者说是收效甚微的.

对于cvs老手,如果它能满足你的一切要求,有什么必要非得转成svn呢,完全没有必要.而对于新手来讲, 似乎,各位老大的遇到的问题, 包括速度慢, 都没有遇到过, 为什么呢, 或许有, 都想办法克服了, 新手的投入主要在svn上而已.

其实与技术本身无关, 而有关爱好者的态度, and unix and unix and unix, 过了.

47 楼 Jan 2007-03-22  

我这里项目157MB，svn co/update速度都挺快的。subclipse就不要说了，一个插件而已，如何代表svn? 要比还是直接比命令行吧 尤其对于repository不在本地的团队，我想svn和cvs更新一遍的速度不会差太多吧，网络才是瓶颈。

所有的东西都无法真正删除，这是好事还是坏事就说不清了，SVN好比数据仓库，CVS好比数据库，没法说哪个不好，只能说你需要哪个。楼主害怕在硬件上破费，可也有不在乎这点开销的。如楼上所说，类似sourceforge.net/kde.org弃cvs用svn的做法，不是没道理的。

另外对于那句反复出现的Unix is not for everyone有点意见:) 其一这个似乎算不上UNIX的哲学。其二它的本意好像和语境也不太着边。

46 楼 宏基小键盘 2007-03-22  

1、客户端非常好用
2、各大开源组织用的基本上已经换成SVN了，自有他们的道理
3、SVN的出现来来就是为了弥补CVS的一些不足

45 楼 noble 2007-03-21  

1、彻底删除有彻底删除的好处，但也有风险。
2、完全希望依靠系统来满足管理上的漏洞是不可行的。
3、任何一个东西都不可能是百分百满足所有需求的，所以，也就有所谓适应性问题，看你觉得哪个重要了。

我这边目前用的是SVN

44 楼 ahuaxuan 2007-03-20  

用svn到现在，觉得它在速度上可能是有点慢，但是还没有到不能接受的地步，我们的项目也很大，我们用idea，所以没有subeclipse的烦恼，总体来说还是不错的，而且还有上面所说的优点，而且我在自己的电脑上也装了svn，上次误删了整个工程delete+commit，居然还是给我找回来了，庆幸啊

43 楼 zhaohb1980 2007-03-20  

SVN的Web客户端WebClient for SVN我配好了，web.xml中的用户名密码是登录用的么？我怎么登录不上去？LZ能告诉一下么？

42 楼 ozzzzzz 2007-03-19  

basicbest 写道

ozzzzzz 写道

这个东西我朋友用过，觉得很好，但是在现在的企业环境下不适合，主要是没有权限系统。
实际上我觉得现在cvs和svn包括cc等scm软件都太复杂，这主要是由于cm的理论基础太复杂了。如果这个时候能够对cm的基础概念进行研究，推出一个lean一些的概念来，然后在按照这个概念构建一个软件会好很多。
实际上作为程序员来说，用到的命令其实有checkin和check out就够了。而面对管理员来说就复杂的多了，当然入手点就在这里。

在和Apache一起用的时候可以进行比较好的权限管理。
也可以使用SVNserver+SSH，但是使用Apache会带来更多的实惠。

具体可以参考
http://svnbook.subversion.org.cn/nightly/index.html

对于楼主提到的第三条，是不是可以给该文件加上适当的权限解决，比如使其不可访问。一般情况下，这种误操作非常少见，本身绝密资料在存放位置上都会有严格的要求，如果和开发文件放在一起似乎属于管理上的疏漏。而且对于大型项目的管理来说，保留痕迹是必要的，万一该文件被发现的时候已经泄露，以后出现法律纠纷的时候发现这个历史已经被你删除了，那个时候谁来承担责任？

sorry 写错了，我的评论是准对GIT的，不是针对svn的。

41 楼 agile_boy 2007-03-19  

  svn和cvs的快慢没有专门比较过（我以前也是用cvs），从我们用svn接近 一年的情况看，现在已经是4千多的reversion了，我们还是用http协议，fs系统，也没有感觉那么慢啊，至少还是在我们开发团队的容忍范围之内。
  不过不支持彻底删除，有时有点别扭，不过对我们team来说，无所谓
  其实svn还是有不少优点的，比如svn switch直接支持repository的url修改，在cvs还是比较麻烦的事情

40 楼 basicbest 2007-03-19  

ozzzzzz 写道

这个东西我朋友用过，觉得很好，但是在现在的企业环境下不适合，主要是没有权限系统。
实际上我觉得现在cvs和svn包括cc等scm软件都太复杂，这主要是由于cm的理论基础太复杂了。如果这个时候能够对cm的基础概念进行研究，推出一个lean一些的概念来，然后在按照这个概念构建一个软件会好很多。
实际上作为程序员来说，用到的命令其实有checkin和check out就够了。而面对管理员来说就复杂的多了，当然入手点就在这里。

在和Apache一起用的时候可以进行比较好的权限管理。
也可以使用SVNserver+SSH，但是使用Apache会带来更多的实惠。

具体可以参考
http://svnbook.subversion.org.cn/nightly/index.html

对于楼主提到的第三条，是不是可以给该文件加上适当的权限解决，比如使其不可访问。一般情况下，这种误操作非常少见，本身绝密资料在存放位置上都会有严格的要求，如果和开发文件放在一起似乎属于管理上的疏漏。而且对于大型项目的管理来说，保留痕迹是必要的，万一该文件被发现的时候已经泄露，以后出现法律纠纷的时候发现这个历史已经被你删除了，那个时候谁来承担责任？

39 楼 squall 2007-03-19  

不觉得很慢啊，至少比CVSNT快太多了，我们有个文档库已经4.5G了，还是在windows上走的http协议，每天有很多人访问
客户端：eclipse + subversive和TortoiseSVN

38 楼 ozzzzzz 2007-03-19  

GIT这个东西我朋友用过，觉得很好，但是在现在的企业环境下不适合，主要是没有权限系统。
实际上我觉得现在cvs和svn包括cc等scm软件都太复杂，这主要是由于cm的理论基础太复杂了。如果这个时候能够对cm的基础概念进行研究，推出一个lean一些的概念来，然后在按照这个概念构建一个软件会好很多。
实际上作为程序员来说，用到的命令其实有checkin和check out就够了。而面对管理员来说就复杂的多了，当然入手点就在这里。

37 楼 JeffreyHsu 2007-03-19  

我们实际使用svn已近一年，发现经常同步不了代码，无法更新也无发提交，即使conflict解决了也提交不了，会报各种各样的错，遇到这样的就直接delete project然后co一个新的，怪无奈的

而且发现eclipse下的svn插件subclipse巨慢无比，经常提交一个项目到死机
发现直接用command line快的多，在eclipse里一个需要5分钟的co操作，用命令行可能只要5秒钟就行了。

36 楼 pig345 2007-03-19  

SVN似乎是要做 版本化的文件系统（svnbook上说的），
所以与一般的版本控制工具不太一样。
原子提交、版本号即为修改集、copy就是Tag/batch、merage可以负向等等，都是比较特别的特性。

另：最近发现有些linux项目用GIT作版本控制，不知道如何。