版本控制系统存储了所有的代码,存储这些代码的地方叫做项目仓库(repository),这个仓库可以放在本机或者专门的服务器下。要注意这个仓库的定期备份工作。通过文件系统或者网络系统可以访问仓库,SVN采用的网络的方式。
一般情况下我们说版本控制的是代码部分,但是实际操作上所有用于构建、发布程序的文件和配置等信息都需要在版本控制工具的控制下,而所有的生成文件(依赖代码生成的,如文档)都不需要放在仓库中。
把仓库中的代码拷贝到我们电脑上,进行修改,这称为工作拷贝(working copy),对于大项目来说,拷贝所有的代码显然并不现实,这需要对仓库的项目进行分割。至于如何分割,SVN以目录的形式分割项目仓库。第一次建立工作拷贝时叫做签出(checking out)。除了签出还有一个概念是导出(export)导出的只是一个项目仓库文件的快照。我们在本地修改代码之后,需要提交到服务器上,这个过程叫做提交(committing)。为了确保一致性,在提交之前你需要进行更新操作,就是和本地代码比较服务器端代码,看着和上次取出来的数据有什么不同地方(主要是团队对代码的修改是否影响到我的部分),这个过程叫做更新(update)。
项目仓库在我们看来会存储我们修改过的没一个版本,但实际上并不是这样,他只是存储了最新的版本以及之前修改的增量过程。同时Subversion存储了必要的历史版本,以提供最快的存取速度。CVS使用时每个文件都有一个版本号,而SubVersion则不是这样,它对项目仓库进行整体编号,这样我们就能将每个版本号视为代码的一个断面。
CSV的版本号 SVN的版本号
所谓版本2.1.12.23,谁知道这是什么东西!?比不上QQ2012这来得好记吧。我们可以使用标签来跟踪代码开发中的重要事件,例如新功能的导入、架构的改变等等。
与分支(branching)对应的概念是主干(trunk),比如我们需要在目前所有开发人员持续修改的QQ软件上发布一个新的版本QQ2013,我们不可能要求所有工作人员停止更新,等待代码发布出去在增加新功能、修改BUG。所以引入了分支,这相当于创建了一个平行于现有代码的另一份代码,变成了一个双头并进的队伍。主团队依然在原来的主干上工作,发布团队则在分支上工作,修改BUG,增添新功能、发布后的维护。这种功能的缺点就是你制造了一个双头蛇,之后不过瘾,又制造了一个双头蛇,再制造,继续制造,继续制造……你一定学过数据结构中的树……控制这种“爆炸”的方法就是只为发布建立分支。更令人吃惊的是这种爆炸居然是可以收敛的。这就是合并(merging),合并可以把代码从分支合并到主干上,可以在分支之间合并,可以在多个分支之间合并。比如我们在发布的QQ2013上发现了一个BUG,那么这个BUG极有可能存在于之前发布的QQ2012和当前的主干上,于是我们修改了发布版上的BUG,合并到主干上。