我对版本控制要晕了,今天才知道Mercurial(Hg)和Bazaar,加上CVS,SVN,Git,Clearcase,他們都算SCM(Software Configuration Mangement软件版本控制管理)工具。
在線託管有GitHub,Google Code,Bitbucket,SourceForge,GitCafe;
客戶端更多啦,海龜客戶端TortoiseSVN,TortoiseHg(烏龜Hg),TortoiseGit(烏龜Git)真有個性,GitHub更是說明有個 吉祥物 真的很重要!- -b 其实只有這句才是重點,下面好無聊估計都知道就當wiki吧。

什么是SCM
在软件工程中,从项目开始到完成发布,中间一定有很多不同的版本,如何track和control这些版本,如何让开发人员并行的工作,如何把大家的代码merge到一起? 于是产生了以版本控制(version control)为核心的SCM(Software Configuration Mangement软件版本控制管理)。历史上SCM也有不同的解释,software configuration management来自于IBM Rational Software,还有software change and configuration management,source configuration management等。

如何进行版本控制
我觉得可以把SCM看成是时光机器,版本控制让你像神(其实也有权限管理)一样管理任何时间点的世界。版本控制流程的基本循环是这样的:
1. 从他人处获取最新的文件树(回到某个时间节点的世界)
2. 对这个版本的树进行一系列修改(改变了那个世界,是原来某时间节点的平行世界)
3. 发布并使其他人可以获得这些修改(确定那个平行世界的存在,其他人也可以来到这个平行世界)

第一个动作,也就是获取一份本地的文件树,称为checkout。我们获取和发布所有修改的地方叫版本库repository,而检出得到的目录则被称为工作目录、工作树。用版本库中的最新文件更新工作拷贝的动作就叫update。有时候这还会涉及到merge,也就是组合不同用户对同一个文件作出的修改。diff命令使我们能够查看树或文件在两个版本之间的变化,它最常见的用途是检查你的工作目录中的本地(未发布的)修改。修改的发布是通过commit命令完成的,它会将工作目录的改变保存到版本库中去。

一个经典的不能回避的问题是,多人修改同版本的同一文件如何处理?
早在操作系统设计中,人们就遇到了类似问题:多进程如何安全地访问访问公共资源或一段代码(临界区)? 因为操作系统必须安全和稳定的特点,多进程得互斥访问临界区,即当一个进程已经访问临界区时,其他进程全部挂起,等待那个进程离开临界区后才能再选一个访问。
类似的,多人协作时,让某人已经checkout一个文件,其他人就不能再checkout,得等他checkin后才能再修改。这样的做法比较悲观,所以可以被称为悲观访问、悲观锁。与之对应的就有乐观锁,因为人还是要比机器聪明,即使最悲观情况有两人默契地修改了同版本的同一文件同一行代码,最后仍可以确定哪个修改是更好的,所以乐观访问就不会有只能同版本同一文件只能一个人修改的不爽了。

TO BE CONTINUED...Mercurial,Git,Clearcase的JQ