svn与cvs的比较及迁移注意事项.docVIP

CVS介绍 CVS是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。CVS是版本控制的利器，目前在Linux和Windows下都有不同版本.工作模式如下：????????CVS服务器（文件版本库）?????/?????|???????\?????（版?本?同?步）???/???????|?????????\开发者1??开发者2???开发者3????????????? SVN介绍 在开放原码软件的世界中, Concurrent Versions System (CVS)長久以来, 一直都是版本控制的不二选择. CVS本身是自由软件, 而且它是 “非锁定式” 的系统 —这让分布广阔的程式设计人员能够分享彼此的工作— 完全符合开放原码世界的合作模式. CVS, 以及它那半混乱式的发展模式, 已经成为开放原码文化的基石. 但是就像许多的工具, CVS 已经开始显露疲能. 比较起来, Subversion 是一个新的工具, 是设计来成为 CVS 的后继者. 设计者要以两个方法来贏得 CVS 使用者的心: 产生一个设计 (还有 外观与感觉) 类似 CVS 的开放原码系统, 以及试著修正 CVS 中最广为人知的缺点. 虽然结果不見得会是版本控制设计的下一个伟大革命, 但是 Subversion 绝对 会是个強力, 可用性高, 而且深具弹性的工具. 两者的比较 总体来讲目前CVS版本管理得技术已经非常成熟,而且不断的增强功能和改进缺陷.以CVS+PYTHON能实现的功能大大增强:如强制更新所有文件的版本号到更高的版本 而SVN起点更新,更有发展潜力. SVN目前对CVS最大的优点如下: 目录版本控制 CVS 只能追踪单独档案的历史, 不过 Subversion 实作了一个 “虛擬” 的版本控管档案系统, 能够依时间追踪整个目录的更动. 目录和档案都被納入版本控管. 最后, 用户端有真正可用的 move (移动) 与 copy 指令. 不可分割的送交 一个送交动作, 不是导致所有更动都送入档案库, 就是完全不会送入. 这让发展人员以逻辑区段建立更动, 并送交更动. 納入版本控管的描述資料 (Meta-data) 每一个档案与目录都附有一组隐形 “性质 (property)”. 你可以自己发明, 并存储任何你想要的键值对. 性质是隨著时间来做版本控管的, 就像档案内容一样. 选择不同的网路层 Subversion 有抽象的档案库存取概念, 可以让人很容易地实作新的网路机制. Subversion “先进” 的网路伺服器, 是 Apache 网页伺服器的一个模组, 它以称为 WebDAV/DeltaV 的 HTTP 变体協定与外界沟通. 这对 Subversion 的穩定性与互通性有很大的帮助, 而且額外提供了许多重要功能: 举例来说, 有身份认证, 授权, 线上压缩, 以及档案库浏览. 另外也有小而独立的 Subversion 伺服器程式, 使用的是自訂的通訊協定, 可以很容易地透过 ssh 以 tunnel 方式使用. 一致的資料处理方式 Subversion 使用二进制差异运算法, 来表示档案的差异, 它对文字 (人类可理解的) 与二进制档案 (人类无法理解) 两类的档案都一视同仁. 这两类的档案都同样地以压缩形能储存在档案库中, 而且档案差异是以两个方向在网路上传送的. 更有效率的分支 (branch) 与标记 (tag) 分支与标记的花费并不必一定要与计划大小成正比. Subversion 建立分支与标记的方法, 就只是复制该计划, 使用的方法就像 hard-link 一样. 所以这些动作只会花费很小, 而且是固定的时间. Hackability Subversion 沒有任何的历史包袱; 它主要是一群共用的 C 程式库, 具有定义完善的 API. 这使得 Subversion 便于维护, 并且可被其它应用程式与程式语言使用. S VN的一些主要不足 当一个专案开始产生分支时, 常常我们得先将目前分支的更动合并至主发展线, 这些被合并的更动, 就称为合并点. Subversion 并不会记住分支已经采用了哪些合并点, 也就是说, 如果在合并更动之后, 在合并的地方又有了更动, 日后当分支发展完毕, 整个分支的更动需要合并至主发展线时, 由于系统不会记得已采用了哪些更动, 而已合并的地方又更动过, 就会造成同一个更动被合并两次, 此时后来的更动几乎可以肯定会造成档案的冲突, 必須由使用者进行排解. 如果系统能够记得合并点的話, 已采用的合并点就毋需再采用, 也就可以减少使用者必須手动进行冲突排解的次数. 档案版本 在 Subversion 中, 版本号