版本控制系统简介RCS/CVS/Subversion

一个版本控制系统最基本的功能就是记录每次修改的地方，并且可以让使用者方便地存取各个版本、比较版本差异。更进一步的，是建立一个多人开发的环境，可以计录每个人的修改，解决版本冲突的问题。版本冲突问题是指两个人同时对一个档案作修改的动作，举个例子说，现在数据库里的版本是A，甲和乙分别把这两个档案拿出来（这个动作通常叫 checkout），在做了一番修改之后，甲先把改变的数据存回去（这个动作通常叫 checkin），这时问题还没有发生，数据库的板本被更新成B，但是当乙 checkin 的时候，问题就来了，乙的版本也是从 A 修改而来的，到底该用甲的修改版还是乙的呢？如果硬把甲的修改用乙的版本盖过去，那甲所花的工夫就全部白费了。最常用的解决办法是用文件按锁定的功能，就是当甲在修改某个档案的时候，会把档案加个 lock 的 flag 让大家知道，这个档案正在被修改，不要去动它。不过像 CVS等进阶的版本控制系统，就算没有做档案锁定的动作，发生版本冲突时，也提功了方便的功能可以把两个版本 merge起来。
       目前有许多商业与开放源码的版本控制系统. 在开放源码界, 最早出现的, 大概就是 SCCS, 其后演变成为 RCS. 这两个都是以个别档案为基础来进行版本控制. 后来就有了 CVS 的出现, 它架构在 RCS 之上, 并且可以处理多个档案的送交 (也就是跟版本控制软件说, 我有这些档案更动过了, 请记住这些更动).

                                                          RCS（Revision Control System）
      一个相当相当古老的工具了，虽然现在大家都是用 CVS 来做版本控制的工具但是如果没有可以使用的 CVS server 那就没有办法使用了，RCS 主要是偏个人使用的，没有像 CVS 有许多强大的功能，也不支持远程档案系统的存取。
     但是在只需要单纯的版本管理功能时，就相当的有用了。建议大家如果在工作站上写程序，或是写文件的时后，可以试着用 RCS 来做版本管理的工作，一开始可能会觉得绑手绑脚的，但是用久了，你一定会发现使用版本控制系统真是好处多多！
     使用 RCS 相当简单，只有几个指令而已，大部份系统都有包含。
     简单的使用方法就是这样： 
1. 建立 RCS 数据库
先在想要保存的程序代码下的目录下建立一个叫 RCS 的目录
mkdir RCS
2. 将档案登入到RCS 数据库
ci filename
这时，RCS 会要你输入 log，就是记录你对这个版本有什么说名的地方，简单说几句就可以了，当然也可以不打，然后会给你一个初始的版本编号，应该是1.1。你会发现到，原来的档案不见了，而在 RCS目录下多了一个叫做 filename,v 的档案，那个档案就是用来记录 filename 的版本演进史的。
3. 把档案取出来
档案不见了，那还有什么戏唱，能够放进去的，当然就一定可以拿出来：
最基本的用法是这样，会取出 filename 的最新版本。
co filename
但是，注意它的属性，是只读的喔，要加上 -l 的参数表示要 lock 才可以做修改的动作，修改完了，再把档案 checkin 回去就完成了版本更新的动作了，这时的版本编号应该是1.2。
另外，co -r filename可以取出指定的版本，但是其属性一定是只读的。
4. 把修改的档案存回RCS 数据库
还是一样，ci filename，不过可以加上 –u 的参数顺便 unlock，如果要继续编辑的话，要加上 –l ，不然会自动把原来目录下的档案删除。
5. 观看一个档案的修改记录
rlog filename
比较版本的差异
rcsdiff -r[version] filename
      大概的使用方法就是这么简单，有了基本版本控制系统的概念之后，要使用 CVS、Subversion 等进阶的版本控制系统，就相当容易了。

   CVS（Concurrent Versions System）

   CVS是继RCS等传统的维护工具之后，新一代的程序开发与维护系统，现在网络上许许多多的 Open Source Project，几乎都是使用 CVS 来做版本控制的工具，它拥有以下的特色：
程序代码版本的储存与维护
程序代码版本的追踪回溯
程序代码版本的分合控制
支持多人合作开发项目
程序代码远程管理维护
程序代码匿名截取
    另外，CVSup 和 CVS 是两个不一样的东西，前者大都是方便使用者可以取得与开发者同步程序代码所的工具，它是透过比对 server/client 之间的 source code cvs id table 来判断那些档案需要修改，在速度上有很大的优势。另外还有一项使用 CVSup 的优点是它可以在你的本地机器上复制整个 CVS repository，允许快速的本地使用 cvs 操作，像 log 和 diff。
    CVS 是给开发人员用的。不过许多 Open Source Project 都会提供 anonymous CVS，通常只有read 的权限。给其它使用者取得他们所想要的版本，主要的作用就是把最新开发的程序代码给喜欢新鲜货的人，让大家一起来测试，对一个 project 的开发，相当有帮助。
CVS 也不支持档案更名. 也就是说, 如果我们想要变更某个档案的名称, 那么它以前所累樍的更动与批注就得丢弃. 它也不支持以目录为单位的变动, 所以要想回复某个时间的目录内容是不可能的.
　　另外，介绍一些好用的GUI的CVS界面
    WinCVS：win32环境下的，不过笔者觉得相当难用。
    Cervisia：KDE的CVS GUI界面，可以和Konqueror整合，使用上感觉相当亲切。

    Subversion 
    一套更好的 CVS! 它同样也是开放源码, 而且架构, 命令列程序界面等, 都刻意模仿 CVS, 为的就是要让习于 CVS 的使用者能够快速上手.
　　目录版本控制
　　在 CVS 中, 一个目录是没有版本历程的. 假如原本一个名为 doc/ 的目录, 在经过一段时间之后, 发现它应该要称为 manual/ 比较恰当, 此时我们只能建立一个新 manual/, 把 doc/ 目录下的档案复制过去, 把manual/ 下的档案新增至 CVS 系统中, 再把 doc/ 删除. 而且必须注意的是, 在档案的复制与删除的过程当中, 我们也同样地遗失了这些档案的历史历程. 版本控制最主要的数据就这么丢掉了!
　　但是在 Subversion 中, 目录跟档案同样都是纳入版本控制之中. 也就是说, 我们可以随时要求Subversion 将某个档案回复到某个时间点的状态, 也可以对目录进行更名的动作.
　　不可分割的送交
　　在 CVS 中, 虽然我们可同时对复数档案进行送交, 但是 CVS 并不保证一次的送交是不可分割的. 也就是说, 如果我们同时对三个档案进行送交, 但是在第二个档案时发生意外状况 (例如档案有冲突, 或是网络断线), 此时 CVS 系统中会有送来的第一个档案的更动, 但是没有第二个与第三个的. CVS 系统里的档案就变成一个与我们预期不一致的状况!
Subversion 的送交就没有上述的问题. 也就是说, 送交的结果, 不是全都进系统, 就是全都没有进系统, 不会只有一部份进系统的状况.
　　更佳的二进制数据处理
　　CVS 虽然号称可以处理二进制的数据 (例如图形文件, Microsoft Word 档案), 但是需要使用者特别设定, 而使用者 常常忘记. 再加上 CVS 会主动更动档案内容, 如列尾符号与关键词展开的功能, 以至于常常在需要将档案回复至过去的状况时, 才发现档案变得无法读取了. 再者, CVS 的档案内容差异算法几乎无法处理二进制档案, 以致于在储存档案上,      
需要耗费大量的空间.
　　Subversion 对上述问题的处理方法有二. 首先, 它不主动更动档案内容, 除非使用者加上这样的设定.再者, 它使用可适用于文字与二进制数据的内容差异算法, 在档案储存上, 文字与二进制数据都具有相同的优势. 现在, 不只是文字数据适合置于版本控制系统中, 连二进制数据也可以很方便地放进来.
　　高效率的分支与标记
   我们可以对已纳入版本控制系统的档案进行标记, 也就是赋与它们一个易记的文字, 日后便可以利用这个易记的文字, 将这些档案回复到某个特定的状态. 但是 CVS 必须对每一个档案加上这样的标记, 档案愈多, 耗时愈久.
　　在 Subversion 系统, 标记是以目录的副本的方式建立的, 而副本是以类似链接的方式来建立. 也就是说, 不管牵涉的目录与档案有多少, 它所花费的时间都是固定的, 不会因为档案愈多而耗时愈久.
　　CVS 最为人所垢病的缺点, 就是它的分支功能相当难以使用. 但是在实际上运用时, 分支功能可以为使用人员增加不少便利. 像是可以藉由使用分支, 将程序代码隔离开来, 让发展人员可以进行大规模更动的同时, 还能让维护人员进行维护. 而 Subversion 的分支, 亦是以目录的副本来实作的, 在观念上更容易学习, 使用起来也更方便.
　　Subversion 的缺点
　　但是 Subversion 亦不全然没有缺点, 它毕章还是一个刚开始发展的系统, 仍然存在一些不易使用的地方.
　　档案保留
　　我们无法取得 Subversion 档案的独占编辑权. 这是因为 Subversion 的工作模式, 是让各个工作的人取得工作复本, 各自编辑后, 再于送交时进行合并. 不过有的时候, 我们还是得要先取得档案的独占编辑权, 像是在编辑图形文件. 此时, 由一个人统一对某个档案进行编辑, 要比事后合并要简单地多了.
　　合并点
　　当一个项目开始产生分支时, 常常我们得先将目前分支的更动合并至主发展线, 这些被合并的更动,就称为合并点. Subversion 并不会记住分支已经采用了哪些合并点, 也就是说, 如果在合并更动之后, 在合并的地方又有了更动, 日后当分支发展完毕, 整个分支的更动需要合并至主发展线时, 由于系统不会记得已采用了哪些更动, 而已合并的地方又更动过, 就会造成同一个更动被合并两次, 此时后来的更动几乎可以肯定会造成档案的冲突, 必须由使用者进行排解. 如果系统能够记得合并点的话, 已采用的合并点就毋需再采用, 也就可以减少使用者必须手动进行冲突排解的次数.
档案版本
　　在 Subversion 中, 版本号码是整个系统共享的. 这个意思就是说, 如果一个项目的档案因修改而有版号的更动, 那么所有档案的版号都会跟着更动. 这对由 CVS 移转过来的使用者是最难以接受的, 需要花一点时间习惯.
　　但是, 在这种全域版号下, 我们无法很简单地回答这样的问题: 某个档案的第一个版本长什么样? 在目前最新版的前两个版本作了什么更动? 你知道, 有些时候, 我们就是需要像这样的功能.
　　I18N, L10N
　　虽然 Subversion 本身架构支持 Unicode, 不过使用者界面还是使用纯英文的环境. 对于多国语言的支持仍有一段路途要走.
                                                                         结语
　　以上简单介绍了 Subversion 与 CVS 的优缺点评比. 虽然 Subversion 才开始发展三年, 直到今年才进入 1.0 版, 但是它所提供的便利性与功能性, 已经凌驾于 CVS 之上. 目前尚有不足的功能, 在活跃的开发团队的手中, 必定能很快地加上去. 有兴趣的读者现在就赶快加入使用 Subversion 的行列吧!
　　一个全新的版本控制系统，企图取代 CVS，提供了比 CVS 更佳的版本管理功能。

 

 

 

三种最新自由软件管理开发工具介绍

http://hi.baidu.com/digast/blog/item/90ff0df7f7239e27730eec37.html

2008-04-10 17:51

        要预测接下来自由软件社区会有什么好玩的工具出现，确实是相当困难的。可是对于目前的国外社区中，有些趋势似乎在逐渐成型。这些部分，国内显然也有些社区朋友已经注意到了，那就是主动的参与相关社区的发展与讨论进而参与成为协助开发的角色。现在就趁这个机会来探讨一下这些专门开发工具的內容，看看他们对自由软件的系统开发及专门管理能有什么帮助。

　　                     版本控制系统：Subversion
        这是目前开放源代码社区中，当红的版本控制系统专案。几乎一般的说法，也就是即将取代CVS(Concurrent Version Control)的开放源代码版本控制系统。CVS一直以来几乎都是开放源代码专门的标准版本控制系统，也就是几乎大多数的开放源代码专门都有提供 CVS 的档案库让一般使用者来取得专门的源代码。但是随着开放源代码社区的快速成长，有许多专案也不断的成长，渐渐的CVS似乎有些瓶颈。于是许多新的版本控制系统陆续出现，例如Aegis，Bitkeeper或是Perforce。相较于CVS，这些后起之秀其实以功能性而言，其实大多好过CVS不少。但是不论是哪一套系统，似乎都多少有些版权上的限制，或者基本上就是商业软件。所以虽然有很多大型开放源代码专门使用这些版本控制系统(例如Linux核心开发就是使用Bitkeeper，而Perl团队则是使用Perforce)，但是却很难像CVS这么广泛地被使用。
　　然而这些新一代的版本控制系统却指出了一些方向，或者也可以说，他们确实提出了一些见解，在专案越来越庞大时，专案管理上到底需要什么样的版本控制系统，而确实也获得了许多肯定。但是这些拥有強大功能的版本控制系统却各自有着不同的问题，例如被Perl核心开发团队所用来进行开发使用的Perforce就是属于商业软件，虽然支援开放源码计划的开发，但是一但进行商业使用，就必须负担一笔不少的软件费用。但是并非所有人都希望多学习另一套的版本控制系统，却只能用来进行某些专案的开发。因此虽然许多看起来在功能性虽然相对于CVS有着绝对的偶遇，但是却无法动摇CVS在开放源代码社区的地位。
　　但是对于许多通过CVS管理的专案却遇到越来越多的问题，例如要在CVS上进行分支，虽然功能上可以達到，但是却也相当困难。类似这样的问题在CVS逐渐发展的过程持续的浮现出来，但是以CVS最初的涉及结构，要修改这些为人所诟病的问题却并不容易。而且CVS的学习曲线相较于后来陆续发出来的各种版本控制系统明显来得陡峭。这许多的原因让CVS团队决定以改变底层的结构来进行时代性的转变，而这个计划正是Subversion专案的起源。
　　首先，Subverion改变了原来CVS一个存档就是一个版本的问题，而是让使用者可以在解决一个问题之后，再一次把所有修改的档案送回服务器上。这么一来，即使我们发现送上去的档案把原来的系统搞乱了，也可以通过回到上次的版本而恢復系统正常的状况。使用Subversion进行系统的分支比起CVS也显得容易许多。因为基本上如果你希望在Subversion上产生系统的一个分支，你只需要将现有版本进行复制就轻松的完成了分支的动作。如果有人使用过CVS来进行分支，大概会觉得得这样的方式简单地近乎不可思议，也因此反而让人不太容易安心。其实因为所谓的分支，其实只是从目前的系统版本复制一份，并且能够保存原来的系统记录(log)，所以Subversion的作法实在是能够确实理解的。另一个使用Subversion来进行分支的大利多则是空间的使用。Subversion在进行复制时，并不真的会把原来的档案复制一份，而只是产生一份连结。因此你可以以非常节省空间的方式来进行复制，当然也就是非常优雅地替你的系统做好分支。
　　于是有人提出了问题：“为什么都2004年了，还有人在写版本控制系统？”因为Subversion虽然大幅改进了CVS的不足，但是却让人有更多的期待。于是SVK利用Subversion的基础开始发展了起来。

　　                    离线版本控制系统：SVK
　　当我们在使用Subversion的时候，似乎有些时候会发现系统完全不灵光了。例如我在火车上想要拿出笔记本电脑来解决某个程序上的问题时，却发现我沒有办法透过Subversion来工作，因为我没办法取得版本控制上的任何信息。等到你终于回到网路世界时，可能得面临解决在你的笔记本电脑使用期间，跟其他人修改的部份冲突。而且当初Subversion刚开始发展时，程式执行的速度实在不特別让人满意。后来在功能部份大致底定之后，开发团队才慢慢修正执行效率的问题，但是这些原因却让SVK正式诞生了。
　　SVK其实是根基于Subversion之上，也就是利用Subversion的档案库，以及大量的 Subversion函式库所开发出来的Perl程式。而且主要的概念在于可以进行分散式管理的版本控制系统，所谓分散式的意义其实就在于每个人都应該要可以简单的复制一份完整的档案库在自己的时中。用比较口语的解释，也就是说，每个人在取出一个Subversion档案库时，其实就可以映射(Mirror)一份在自己的电脑中，而这一份映射就可以包含所有修改內容以及记录档案的完整资料库。
　　这样一来，如果你在你的笔记本电脑取得了一份完整的档案映射，你所有关于档案库的操作都可以在你的电脑进行。因此即使你在火车上或飞机上也都可以正常工作，而且你每次工作到一个段落时，也都可以把档案送回(commit)档案库中，只不过这时候你的档案库其实是在你自己的电脑中，不过至少你可以安心的进行自己本地的版本控制。
　　可是接下来还是有另一个棘手的问题，也就是当你在笔记本电脑上进行工作时，还是可能发生和其他人修改了同样档案的问题，因此只要你想要把自己映射下来的这一份档案库和本地的档案库进行同步化，合并是非常重要的，而且免不了的状况。既然大量合并是分散式版本控制必须面对的一个问题，因此如果每次合并都必须人工去确定就显得不太智慧了。所以SVK发展出自己的smerge，也就是「聪明的合并方式」，透过这样的合并方式，只要大家修改的部份沒有造成冲突，SVK可以自动的完成合并的动作。而最近更进步的发展则是当你在送回档案时，发现修改的部分发生冲突，那么SVK可以呼叫图形介面的合并工具程式来帮助你完成合并的工作。这个部份其实满重要的，因为在Subversion的部份，一但发现修改部份产生冲突，他会产生新的档案，并且标示两边发生冲突的状况，但是却必须手动去进行解决，而没有好的工具可以帮助使用者进行。因此这一部份，SVK就显得平易近人多了。

　　                 专门追踪系统RT及RTx::Foundry
　　刚刚我们所提到的两个都是关于版本控制，这对于专门的开发占有非常重要的地位。很多人可能并不觉得，但是这些人却通常花了更多时间工人智慧来进行类似的工作。而除了专门开发之外，专门管理也是非常重要的一部份，尤其当一个专门慢慢成长，参与的专门成员也慢慢增加时，要如何管理专门的进行就显得非常重要了。当然，进行工作管理的重要部份就是工作的安排以及追踪。
　　这种事件追踪的系统其实并不少见，例如有名的Bugzilla就是很好的例子，而另外一套相当受到欢迎的则是RT。当然，以单纯的事件追踪功能而言，两套系统都相当足以应付大多数的需求。但是以跨平台的容易性与方便性来说，RT发挥的空间就占有较多的优势，尤其在Windows上的安装，这对Bugzilla几乎是非常难以达成的，可是RT却有已经打包好的安装套件，使用传统的Windows“下一步”安装法，很快就可以装起一套RT。
　　利用RT，可以让专门的计划与工作的分配与追踪变得十分容易。对于RT来說，每个专案就是一个“表單”，而专案的每一个工作项目则是一个“申请单”。因此当我们有了一个新的表单时，也就是我们开了一个新的专案。接下来，只要关于这个专门的相关工作，我們就透过这个专案的申请单来控制。当然，每个工作都可以指定给专门中的成员。所以我们可以很快的掌握专门中有那些待解决的工作，而且谁应该来负责这些工作。
　　透过上面的方式，我们可以很简单的追踪专案中的各个工作项目的状态与进度，并且透过系统进行讨论。但是对于一个完整的专案来說，我们需要的东西更多，就像sourceforge一樣，我们并不是只有事件追踪，我们还需要管理文件，系统的版本以及各式各样的讨论。而RTx::Foundry就是以RT为底层架构，结合各种资源所产生的专案管理工具。
　　RTx::Foundry其实是整合了RT，Kwiki，Sympa，以及Subversion的复合式专门管理介面，也就是說，他只是所有这些套件的统一介面，而所有的操作就透过这些套件原来已经运行的十分顺畅的功能来进行。而且这个计划目前还在中研院继续发展中，目前也有更完整的专门计划支持，所以专案的管理員可以利用RTx::Foundry来管理专案的日历以及相关的时程管理。不但如此，这项计划也受到许多国外的开放源代码社区的重视，当然还吸引一些国外专门进驻使用。