|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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 和 硬盘 去做没必要的重复事情了. |
| 返回顶楼 | |
|
发表时间：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那样的扩展支持离线操作。 |
| 返回顶楼 | |
|
发表时间：2007-06-11
我的项目配了Subversion，我用eclipse把工程提交上去，但是尚未找到在linux服务器上工程存储地方，不知道哪位朋友能帮助一下？
|
| 返回顶楼 | |
|
发表时间：2007-06-19
除了Subclipse插件有没有更好的插件, 这个插件我觉得真是不太好用, 还是我不太会的原因?
除了大家提的速度慢(尤其是同步简直是慢得不行)的问题. 我还有以下一些问题请教大家有没有好的解决方案. 1. Update他连Update了哪些文件都没有.(以前我没有很好的设置，设置一下就可以出来这个update的列表) 2. 改文件夹经常没有办法提交. 出现莫名的错误. 3. 好象也没有很方便的去比较以前两个版本的差异的方法. 请. |
| 返回顶楼 | |
