软件版本管理和发布版本
2010-11-22 10:41:01 
阿炯
这张图上分成了四个时期：
史前时期：1982年的RCS。现在你可能还能在Unix的发布包中找到它。
古典时期：1990年的CVS(经典的SCM管理器，可惜不能track目录和文件名的改变，今天这个东西已经过时了)，1985年的PVCS，1992年的clearcase(价格贵，功能复杂，当然今天也有很多公司在用)，微软的VSS(Welcome to Hell)，90年代中期的Perforce(P4，这个工具今天都还在被广泛地使用，尤其是那些中等大小却有着大量开发团队的公司，现在是Google 内部最大的代码管理器)。
中世纪时期：SVN(Linus很不喜欢SVN，2006年引入了Git)，AccuRev(强力支持branch和merge，其扮演了一个很重要角色帮助社区脱离clearcase和CVS)，
文艺复兴时期：BitKeeper——Sun的内部管理工具，Linux的内核代码2002年也用这个工具，其实，很多开源工程都在用这个工具，2005年这个工具的东家BitMover对大家对BitKeeper逆向工程很不满，于是停止支持开源，于是出现了Git。
Git的第一个版本是Linux之父Linus Torvalds亲手操刀设计和实现的(据说只用了一个周末)，Linus不仅仅给出一个原始设计(简单的、干净的、天才的)，同时，他也用自己那独一无二的风格催生了这个项目。
在Linus介绍Git的著名的演讲中，他强烈地批评(好吧，应该算是侮辱)了CVS，SVN，和Perforce：“Subversion是史上最毫无意义的项目，从项目开始就是这样了”，“如果你喜欢CVS，那么你现在应该在某个精神病研究中心或是别的地方”，“别在用Preforce了，它是十分糟糕和可悲的，这绝对绝对是真的”。无论是反对还是喜欢，Linus的确是改变了历史——中世纪已经过去了，现在的世界由分布式系统主宰，以及消除 branch和merge的恐惧。
Git 基于 DAG 结构 (Directed Acyclic Graph)，其运行起来相当的快。在Git发布后的来年，世界上所有的大型的开源项目全部从Subversion迁移到了Git上，www.github.com真是很大，这可能是这具星球上最强大最牛最酷的SCM系统了。Git可能并不是最简单的，但它一定会是未来十年的主流(有空读读这本书——Git Internals)。
Mercurial (Hg) 第一次出现在2005年4月，也是因为BitKeeper不免费了。Hg可以和Git在一起使用，见：http://mercurial.selenic.com/wiki/HgGit。但是Hg和Git在设计上不一样，他们对提交/变更的概念是一样的，只不过Git用tree来实现，而Hg则是用扁平的文件和目录来实现(revlog)，设计细节可参看：http://mercurial.selenic.com/wiki/Design和 http://mercurial.selenic.com/wiki/DeveloperInfo。
Darcs (Darcs Advanced Revision Control System)是另一个让你摆脱Subversion和CVS的工具，2002年开始，今年是2.5版。它的优势是性能，以及他与众不同的历史版本管理 ——管理patches而不是snapshot(提交/修改)，当然这样一来，历史改变看上去很不好懂。
Bazaar (bzr) 是另一个开源的 DVCS，它试图给SCM的世界里带来一些新的东西。其由Canonical开发(Ubuntu的那个公司)，在2008年成为GNU。
Plastic在2006年出现，强力地支持branch和merge，其还提供了强大的图示，包括3D的版本树，Plastic主要是为了让中等开发团队使用，介于大型的团队(ClearCase)和小型的团队(Subversion)之间。
Team Foundation Server (TFS)，微软的新一代SCM工具，主要是为了VSS的失败负责，但是他还不是版本管理上还是很强，只不过它集成了一大堆各种各样的工具，比如：issue tracking，test management等。
软件发布版本区别介绍-Alpha,Beta,RC,Release
软件版本阶段说明
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。alpha就是α，beta就是β。alpha版就是比beta还早的测试版，一般都是内部测试的版本。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
Stable版：稳定版。在开源软件中，都有stable版，这个就是开源软件的最终发行版，用户可以放心大胆的用了。
对于商业软件，还有如下的划分：
RTM版：全称为Release to Manufacture，工厂版。改版程序已经固定，就差工厂包装、光盘印图案等工作了。程序代码开发完成之后，要将母片送到工厂大量压片，这个版本就叫做RTM版。所以说，RTM版的程序码一定和正式版一样。但是和正式版也有不一样的地方：例如正式版中的OEM不能升级安装，升级版要全新安装的话会检查旧版操作系统光盘等，这些就是RTM和正式版不同的地方，但是它们的主要程序代码都是一样的。
OEM版：厂商定制版。只能随机器出货，不能零售。只能全新安装，不能从旧有操作系统升级。如果买笔记型计算机或品牌计算机就会有随机版软件。包装不像零售版精美，通常只有一面CD和说明书(授权书)。
EVAL版：评估版。就是有30或者60天等使用期限的版本。功能上和零售版无乎没有区别。
RTL版：Retail.(零售版)，这个版本就是真正发售的版本，有漂亮的包装、光盘、说明书等东西和高昂的价格。
互联网巨头们的一些代码管理工具经历
1、两个软件同时诞生
2005年4月，Larry发现有Linux内核开发者违反了协议，正在对自己的宝贝软件BitKeeper做逆向工程，他怒不可遏，撤销了Linux的使用许可。Linux一下子面临者没有源码管理系统的窘境！
这件事情影响很大，第一，Linus Torvalds不得不停下内核的开发和管理工作，开始开发Git。第二，它促使Olivia Mackall发布了几周前开发的Mercurial v0.1 ，和Git一样，这也是一个可扩展的分布式版本控制系统。
两个分布式版本控制系统可以说是同时起步。
很明显，顶着Linux光环的Git（当然它自身非常优秀）受到了更多人的欢迎，很多公司选择了Git，其中就包括互联网巨头Facebook。
随着业务的飞速发展，Facebook的代码库也开始以惊人的速度增长。单单是2013年，Facebook的Git代码仓库就提交了4.4万个文件，1700万行代码，甚至比Linux内核的规模更庞大，更复杂。
更要命的是，Facebook和另外一个巨头Google一样，把公司的所有项目代码都“塞”到了一个代码库中！为什么要单一代码库的策略呢？这么做有很多好处：
(1) 统一的版本化管理，不需要fork 共享库，没有跨代码库merge复制代码的痛苦
(2) 广泛的代码共享和复用
(3) 简化的依赖管理
(4) 跨团队的合作很方便
2、Faceboo决定抛弃Git
可是，随着单一代码库的飞速增长，Git操作变得越来越慢。Facebook的工程师对未来几年的代码库规模做了估计，创建了一个虚拟仓库做一个模拟，结果让人震惊，基本的Git命令都需要45分钟才能完成！
必须得寻找解决方案了！
Facebook组建了一个团队，专门来解决这个问题。他们先是联系了Git维护者，但是要想解决Facebook的问题，Git内部必须得做一些深度的代码修改不可。
所以Git维护者的回复是：你们的代码库太大了，应该分拆代码库......
Git社区对于提升单一超大代码库的性能并不是十分积极，因为很少人这么用啊！
Git这条路走不通，Facebook又考虑了闭源的Perforce，这也是一个老牌的版本控制系统，成立于1995年。Salesforce、Netflix、SAP、迪士尼、Intuit和纽约证券交易所都是它的客户，Google也曾经用过，Perforce在游戏领域是领导者，游戏厂商前20强有18家在用Perforce做版本控制。
在和Perforce的销售工程师接触的时候，Facebook发现Perforce在“读取和写入节点的本地一致性存在缺陷。”不过Perforce并不认为这是一个大问题，也没有计划来解决它。
放弃了Perforce以后，一个有丰富Mercurial使用经验的工程师建议考虑一下Mercurial。Mercurial原用Python写成，采用了面向对象的各种模式，架构更简洁，更容易扩展。
比如对于Facebook这样大规模的存储库，一个主要的瓶颈就是找出哪些文件发生了变化。Git的办法是检查每个文件，随着文件数量的增加，就会变得越来越慢。
Facebook内部有个工具叫做watchman，可以检测文件的状态变化，Mercurial 良好设计使得和watchman的集成非常简单，最终集成了watchman的Mercurial在查看文件状态时，比Git快了5倍以上。
Mercurial还有几个很好的抽象，例如filelog，这个数据结构表示每个文件的每次修订，Facebook通过remotefilelog扩展了这个接口，使得超大存储库的pull和clone速度提升了10倍以上，从几分钟缩短到几秒钟。
Mercurial社区也非常开放，愿意和Facebook合作，为了解决Facebook遇到的问题，可以对Mercurial做出重大变革。
双方合作相当良好，Facebook从Git向Mercurial迁移的时候，在一年半的时间内贡献了500多个补丁，包括新的图算法，用C语言重写性能关键的部分等等。
Mercurial则认真地审阅这些补丁，主动帮助Facebook解决扩展性问题，在设计新功能的时候也会把Facebook的问题考虑在内。
这和当时的Git社区形成了鲜明的对比。十年后，Git也做出了重大改进，可以很好地处理非常大的单一存储库，但Facebook不会再迁移回来了。
3、Google 发明新轮子
说完了Facebook，再来说说Google；谷歌的代码库更大，更加吓人。截止到2015年，这个代码库一共有20亿行代码，占据了86T的空间。除了Chrome和Android之外，大部分Google产品的代码都保存在一个代码库中。
Google最早用的版本控制系统是闭源的Perforce，可见在创业初期，像版本管理这样的工具，大家都是拿来就用的，不考虑什么开源不开源的。为了支撑自己业务的发展，Google不断地想办法扩展Perforce，但是扩展也是到了尽头：CPU超负荷运转，时不时出现TCP连接失败。
Google也考虑了Git，但当时Git的主流观点是：应该使用更多更小的代码库。这和Google单一代码库的理念是完全相反。就像2005年Linus被迫发明Git一样，Google也被迫发明了自己新的版本管理系统：Piper。
新工具开发起来很容易，但是把数据从Perforce迁移到Piper非常难。在过去的11年间，Perforce已经深深地融入了Google的生态系统，基于Perforce Google已经开发了300多种工具。
2010年，Oracle状告Google，指控它在Android中使用了未经授权的Java API，这给Google敲响了警钟，千万不用复制Perforce的API。
最后Google工程师不得不采用了“洁净室”的技术，由独立的，对Perforce API一无所知的工程师来进行设计。向Piper的迁移花费了4年的时候，才大功告成。
4、小结
Facebook和Google都是标准的互联网巨头，在他们代码库的发展过程中，一直坚持单一代码库的策略，都“抛弃”了Git。
Facebook选择现成开源软件Mercurial，疯狂魔改，使其满足自己的要求。Google则选择发明一个新轮子Piper，花费巨大经历进行迁移。
他们所做的事情，不是一般公司能干的，对绝大多数公司来说，选择Git就足够了。
史前时期：1982年的RCS。现在你可能还能在Unix的发布包中找到它。
古典时期：1990年的CVS(经典的SCM管理器，可惜不能track目录和文件名的改变，今天这个东西已经过时了)，1985年的PVCS，1992年的clearcase(价格贵，功能复杂，当然今天也有很多公司在用)，微软的VSS(Welcome to Hell)，90年代中期的Perforce(P4，这个工具今天都还在被广泛地使用，尤其是那些中等大小却有着大量开发团队的公司，现在是Google 内部最大的代码管理器)。
中世纪时期：SVN(Linus很不喜欢SVN，2006年引入了Git)，AccuRev(强力支持branch和merge，其扮演了一个很重要角色帮助社区脱离clearcase和CVS)，
文艺复兴时期：BitKeeper——Sun的内部管理工具，Linux的内核代码2002年也用这个工具，其实，很多开源工程都在用这个工具，2005年这个工具的东家BitMover对大家对BitKeeper逆向工程很不满，于是停止支持开源，于是出现了Git。
Git的第一个版本是Linux之父Linus Torvalds亲手操刀设计和实现的(据说只用了一个周末)，Linus不仅仅给出一个原始设计(简单的、干净的、天才的)，同时，他也用自己那独一无二的风格催生了这个项目。
在Linus介绍Git的著名的演讲中，他强烈地批评(好吧，应该算是侮辱)了CVS，SVN，和Perforce：“Subversion是史上最毫无意义的项目，从项目开始就是这样了”，“如果你喜欢CVS，那么你现在应该在某个精神病研究中心或是别的地方”，“别在用Preforce了，它是十分糟糕和可悲的，这绝对绝对是真的”。无论是反对还是喜欢，Linus的确是改变了历史——中世纪已经过去了，现在的世界由分布式系统主宰，以及消除 branch和merge的恐惧。
Git 基于 DAG 结构 (Directed Acyclic Graph)，其运行起来相当的快。在Git发布后的来年，世界上所有的大型的开源项目全部从Subversion迁移到了Git上，www.github.com真是很大，这可能是这具星球上最强大最牛最酷的SCM系统了。Git可能并不是最简单的，但它一定会是未来十年的主流(有空读读这本书——Git Internals)。
Mercurial (Hg) 第一次出现在2005年4月，也是因为BitKeeper不免费了。Hg可以和Git在一起使用，见：http://mercurial.selenic.com/wiki/HgGit。但是Hg和Git在设计上不一样，他们对提交/变更的概念是一样的，只不过Git用tree来实现，而Hg则是用扁平的文件和目录来实现(revlog)，设计细节可参看：http://mercurial.selenic.com/wiki/Design和 http://mercurial.selenic.com/wiki/DeveloperInfo。
Darcs (Darcs Advanced Revision Control System)是另一个让你摆脱Subversion和CVS的工具，2002年开始，今年是2.5版。它的优势是性能，以及他与众不同的历史版本管理 ——管理patches而不是snapshot(提交/修改)，当然这样一来，历史改变看上去很不好懂。
Bazaar (bzr) 是另一个开源的 DVCS，它试图给SCM的世界里带来一些新的东西。其由Canonical开发(Ubuntu的那个公司)，在2008年成为GNU。
Plastic在2006年出现，强力地支持branch和merge，其还提供了强大的图示，包括3D的版本树，Plastic主要是为了让中等开发团队使用，介于大型的团队(ClearCase)和小型的团队(Subversion)之间。
Team Foundation Server (TFS)，微软的新一代SCM工具，主要是为了VSS的失败负责，但是他还不是版本管理上还是很强，只不过它集成了一大堆各种各样的工具，比如：issue tracking，test management等。
软件发布版本区别介绍-Alpha,Beta,RC,Release
软件版本阶段说明
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。alpha就是α，beta就是β。alpha版就是比beta还早的测试版，一般都是内部测试的版本。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
Stable版：稳定版。在开源软件中，都有stable版，这个就是开源软件的最终发行版，用户可以放心大胆的用了。
对于商业软件，还有如下的划分：
RTM版：全称为Release to Manufacture，工厂版。改版程序已经固定，就差工厂包装、光盘印图案等工作了。程序代码开发完成之后，要将母片送到工厂大量压片，这个版本就叫做RTM版。所以说，RTM版的程序码一定和正式版一样。但是和正式版也有不一样的地方：例如正式版中的OEM不能升级安装，升级版要全新安装的话会检查旧版操作系统光盘等，这些就是RTM和正式版不同的地方，但是它们的主要程序代码都是一样的。
OEM版：厂商定制版。只能随机器出货，不能零售。只能全新安装，不能从旧有操作系统升级。如果买笔记型计算机或品牌计算机就会有随机版软件。包装不像零售版精美，通常只有一面CD和说明书(授权书)。
EVAL版：评估版。就是有30或者60天等使用期限的版本。功能上和零售版无乎没有区别。
RTL版：Retail.(零售版)，这个版本就是真正发售的版本，有漂亮的包装、光盘、说明书等东西和高昂的价格。
互联网巨头们的一些代码管理工具经历
1、两个软件同时诞生
2005年4月，Larry发现有Linux内核开发者违反了协议，正在对自己的宝贝软件BitKeeper做逆向工程，他怒不可遏，撤销了Linux的使用许可。Linux一下子面临者没有源码管理系统的窘境！
这件事情影响很大，第一，Linus Torvalds不得不停下内核的开发和管理工作，开始开发Git。第二，它促使Olivia Mackall发布了几周前开发的Mercurial v0.1 ，和Git一样，这也是一个可扩展的分布式版本控制系统。
两个分布式版本控制系统可以说是同时起步。
很明显，顶着Linux光环的Git（当然它自身非常优秀）受到了更多人的欢迎，很多公司选择了Git，其中就包括互联网巨头Facebook。
随着业务的飞速发展，Facebook的代码库也开始以惊人的速度增长。单单是2013年，Facebook的Git代码仓库就提交了4.4万个文件，1700万行代码，甚至比Linux内核的规模更庞大，更复杂。
更要命的是，Facebook和另外一个巨头Google一样，把公司的所有项目代码都“塞”到了一个代码库中！为什么要单一代码库的策略呢？这么做有很多好处：
(1) 统一的版本化管理，不需要fork 共享库，没有跨代码库merge复制代码的痛苦
(2) 广泛的代码共享和复用
(3) 简化的依赖管理
(4) 跨团队的合作很方便
2、Faceboo决定抛弃Git
可是，随着单一代码库的飞速增长，Git操作变得越来越慢。Facebook的工程师对未来几年的代码库规模做了估计，创建了一个虚拟仓库做一个模拟，结果让人震惊，基本的Git命令都需要45分钟才能完成！
必须得寻找解决方案了！
Facebook组建了一个团队，专门来解决这个问题。他们先是联系了Git维护者，但是要想解决Facebook的问题，Git内部必须得做一些深度的代码修改不可。
所以Git维护者的回复是：你们的代码库太大了，应该分拆代码库......
Git社区对于提升单一超大代码库的性能并不是十分积极，因为很少人这么用啊！
Git这条路走不通，Facebook又考虑了闭源的Perforce，这也是一个老牌的版本控制系统，成立于1995年。Salesforce、Netflix、SAP、迪士尼、Intuit和纽约证券交易所都是它的客户，Google也曾经用过，Perforce在游戏领域是领导者，游戏厂商前20强有18家在用Perforce做版本控制。
在和Perforce的销售工程师接触的时候，Facebook发现Perforce在“读取和写入节点的本地一致性存在缺陷。”不过Perforce并不认为这是一个大问题，也没有计划来解决它。
放弃了Perforce以后，一个有丰富Mercurial使用经验的工程师建议考虑一下Mercurial。Mercurial原用Python写成，采用了面向对象的各种模式，架构更简洁，更容易扩展。
比如对于Facebook这样大规模的存储库，一个主要的瓶颈就是找出哪些文件发生了变化。Git的办法是检查每个文件，随着文件数量的增加，就会变得越来越慢。
Facebook内部有个工具叫做watchman，可以检测文件的状态变化，Mercurial 良好设计使得和watchman的集成非常简单，最终集成了watchman的Mercurial在查看文件状态时，比Git快了5倍以上。
Mercurial还有几个很好的抽象，例如filelog，这个数据结构表示每个文件的每次修订，Facebook通过remotefilelog扩展了这个接口，使得超大存储库的pull和clone速度提升了10倍以上，从几分钟缩短到几秒钟。
Mercurial社区也非常开放，愿意和Facebook合作，为了解决Facebook遇到的问题，可以对Mercurial做出重大变革。
双方合作相当良好，Facebook从Git向Mercurial迁移的时候，在一年半的时间内贡献了500多个补丁，包括新的图算法，用C语言重写性能关键的部分等等。
Mercurial则认真地审阅这些补丁，主动帮助Facebook解决扩展性问题，在设计新功能的时候也会把Facebook的问题考虑在内。
这和当时的Git社区形成了鲜明的对比。十年后，Git也做出了重大改进，可以很好地处理非常大的单一存储库，但Facebook不会再迁移回来了。
3、Google 发明新轮子
说完了Facebook，再来说说Google；谷歌的代码库更大，更加吓人。截止到2015年，这个代码库一共有20亿行代码，占据了86T的空间。除了Chrome和Android之外，大部分Google产品的代码都保存在一个代码库中。
Google最早用的版本控制系统是闭源的Perforce，可见在创业初期，像版本管理这样的工具，大家都是拿来就用的，不考虑什么开源不开源的。为了支撑自己业务的发展，Google不断地想办法扩展Perforce，但是扩展也是到了尽头：CPU超负荷运转，时不时出现TCP连接失败。
Google也考虑了Git，但当时Git的主流观点是：应该使用更多更小的代码库。这和Google单一代码库的理念是完全相反。就像2005年Linus被迫发明Git一样，Google也被迫发明了自己新的版本管理系统：Piper。
新工具开发起来很容易，但是把数据从Perforce迁移到Piper非常难。在过去的11年间，Perforce已经深深地融入了Google的生态系统，基于Perforce Google已经开发了300多种工具。
2010年，Oracle状告Google，指控它在Android中使用了未经授权的Java API，这给Google敲响了警钟，千万不用复制Perforce的API。
最后Google工程师不得不采用了“洁净室”的技术，由独立的，对Perforce API一无所知的工程师来进行设计。向Piper的迁移花费了4年的时候，才大功告成。
4、小结
Facebook和Google都是标准的互联网巨头，在他们代码库的发展过程中，一直坚持单一代码库的策略，都“抛弃”了Git。
Facebook选择现成开源软件Mercurial，疯狂魔改，使其满足自己的要求。Google则选择发明一个新轮子Piper，花费巨大经历进行迁移。
他们所做的事情，不是一般公司能干的，对绝大多数公司来说，选择Git就足够了。
该文章最后由 阿炯 于 2024-07-22 14:20:44 更新，目前是第 2 版。