是时候从抽象转到具体了,在本小节,我们会展示一个Subversion真实使用的例子。
你已经阅读过了关于工作拷贝的内容,现在我们要讲一讲客户端怎样建立和使用它。
一个Subversion工作拷贝是你本地机器一个普通的目录,保存着一些文件,你可以任意的编辑文件,而且如果是源代码文件,你可以像平常一样编译,你的工作拷贝是你的私有工作区,在你明确的做了特定操作之前,Subversion不会把你的修改与其他人的合并,也不会把你的修改展示给别人。
当你在工作拷贝作了一些修改并且确认它们工作正常之后,Subversion提供了一个命令可以“发布”你的修改给项目中的其他人(通过写到版本库),如果别人发布了各自的修改,Subversion提供了手段可以把这些修改与你的工作目录进行合并(通过读取版本库)。
一个工作拷贝也包括一些由Subversion创建并维护的额外文件,用来协助执行这些命令。通常情况下,你的工作拷贝每一个文件夹有一个以.svn
为名的文件夹,也被叫做工作拷贝管理目录,这个目录里的文件能够帮助Subversion识别哪一个文件做过修改,哪一个文件相对于别人的工作已经过期了。
一个典型的Subversion的版本库经常包含许多项目的文件(或者说源代码),通常每一个项目都是版本库的子目录,在这种安排下,一个用户的工作拷贝往往对应版本库的的一个子目录。
举一个例子,你的版本库包含两个软件项目,paint
和calc
。每个项目在它们各自的顶级子目录下,见图 2.6 “版本库的文件系统”。
为了得到一个工作拷贝,你必须检出(check
out)版本库的一个子树,(术语“check out”听起来像是锁定或者保存资源,实际上不是,只是简单的得到一个项目的私有拷贝),举个例子,你检出 /calc
,你可以得到这样的工作拷贝:
$ svn checkout http://svn.example.com/repos/calc A calc A calc/Makefile A calc/integer.c A calc/button.c $ ls -A calc Makefile integer.c button.c .svn/
列表中的A表示Subversion增加了一些条目到工作拷贝,你现在有了一个/calc
的个人拷贝,有一个附加的目录—.svn
—保存着前面提及的Subversion需要的额外信息。
假定你修改了button.c
,因为.svn
目录记录着文件的修改日期和原始内容,Subversion可以告诉你已经修改了文件,然而,在你明确告诉它之前,Subversion不会将你的改变公开。将改变公开的操作被叫做提交(committing,或者是checking
in)修改到版本库。
发布你的修改给别人,你可以使用Subversion的提交(commit)命令:
$ svn commit button.c Sending button.c Transmitting file data . Committed revision 57.
这时你对button.c
的修改已经提交到了版本库,如果其他人取出了/calc
的一个工作拷贝,他们会看到这个文件最新的版本。
假设你有个合作者,Sally,她和你同时取出了/calc
的一个工作拷贝,你提交了你对button.c
的修改,Sally的工作拷贝并没有改变,Subversion只在用户要求的时候才改变工作拷贝。
要使项目最新,Sally可以要求Subversion更新她的工作备份,通过使用更新(update)命令,将结合你和所有其他人在她上次更新之后的改变到她的工作拷贝。
$ pwd /home/sally/calc $ ls -A .svn/ Makefile integer.c button.c $ svn update U button.c
svn update命令的输出表明Subversion更新了button.c
的内容,注意,Sally不必指定要更新的文件,subversion利用.svn
以及版本库的进一步信息决定哪些文件需要更新。
一个svn commit操作可以作为一个原子事务操作发布任意数量文件和目录的修改,在你的工作拷贝里,你可以改变文件内容、删除、改名和拷贝文件和目录,然后作为一个整体提交。
在版本库中,每一次提交被当作一次原子事务操作:要么所有的改变发生,要么都不发生,Subversion努力保持原子性以应对程序错误、系统错误、网络问题和其他用户行为。
每当版本库接受了一个提交,文件系统进入了一个新的状态,叫做一次修订(revision),每一个修订版本被赋予一个独一无二的自然数,一个比一个大,初始修订号是0,只创建了一个空目录,没有任何内容。
图 2.7 “版本库”可以更形象的描述版本库,想象有一组修订号,从0开始,从左到右,每一个修订号有一个目录树挂在它下面,每一个树好像是一次提交后的版本库“快照”。
需要特别注意的是,工作拷贝并不一定对应版本库中的单个修订版本,他们可能包含多个修订版本的文件。举个例子,你从版本库检出一个工作拷贝,最近的修订号是4:
calc/Makefile:4 integer.c:4 button.c:4
此刻,工作目录与版本库的修订版本4完全对应,然而,你修改了button.c
并且提交之后,假设没有别的提交出现,你的提交会在版本库建立修订版本5,你的工作拷贝会是这个样子的:
calc/Makefile:4 integer.c:4 button.c:5
假设此刻,Sally提交了对integer.c
的修改,建立修订版本6,如果你使用svn update来更新你的工作拷贝,你会看到:
calc/Makefile:6 integer.c:6 button.c:6
Sally对integer.c
的改变会出现在你的工作拷贝,你对button.c
的改变还在,在这个例子里,Makefile
在4、5、6修订版本都是一样的,但是Subversion会把他的Makefile
的修订号设为6来表明它是最新的,所以你在工作拷贝顶级目录作一次干净的更新,会使得所有内容对应版本库的同一修订版本。
对于工作拷贝的每一个文件,Subversion在管理区域.svn/
记录两项关键的信息:
工作文件所作为基准的修订版本(叫做文件的工作修订版本)和
一个本地拷贝最后更新的时间戳。
给定这些信息,通过与版本库通讯,Subversion可以告诉我们工作文件是处与如下四种状态的那一种:
文件在工作目录里没有修改,在工作修订版本之后没有修改提交到版本库。svn commit操作不做任何事情,svn update不做任何事情。
在工作目录已经修改,从基本修订版本之后没有修改提交到版本库。本地修改没有提交,因此svn commit会成功的提交,svn update不做任何事情。
这个文件在工作目录没有修改,但在版本库中已经修改了。这个文件最终将更新到最新版本,成为当时的公共修订版本。svn commit不做任何事情,svn update将会取得最新的版本到工作拷贝。
这个文件在工作目录和版本库都得到修改。一个svn commit将会失败,这个文件必须首先更新,svn update命令会合并公共和本地修改,如果Subversion不可以自动完成,将会让用户解决冲突。
这看起来需要记录很多事情,但是svn status命令可以告诉你工作拷贝中文件的状态,关于此命令更多的信息,请看“svn status”一节。
作为通常的原则,Subversion期望尽可能的灵活,一个灵活性的表现就是能够在工作拷贝中混合有不同的修订版本。
起初,为什么把这种灵活性看作一种特性并没有完全看清楚,这也不是一个任务。完成了提交之后,干净的提交的文件比其他文件有更加新的版本,这看起来有些混乱,但是像以前说过的,通过svn update可以使整个版本统一起来, 怎么会有人故意的混合版本呢?
假设你的项目非常复杂,有时候需要强制地使工作拷贝的一部分“回到”某一个日期,你可以在第3章学习如何操作。或许你也希望测试某一目录下子模块早期的版本,或许你想检查某一文件过去的一系列版本在最新目录树环境下的表现。
无论你在工作拷贝中如何利用混合版本,对于这种灵活性是有限制的。
首先,你不可以提交一个不是完全最新的文件或目录,如果有个新的版本存在于版本库,你的删除操作会被拒绝,这防止你不小心破坏你没有见到的东西。
第二,如果目录已经不是最新的了,你不能提交一个目录的元数据更改。你将会在第6章学习附加“属性”,一个目录的工作修订版本定义了许多条目和属性,因而对一个过期的版本提交属性会破坏一些你没有见到的属性。