搜索
Subversion使用指南主要的参考资料是《Subversion权威指南:针对Subversion1.6:(编译自r3600/r3578)》BenCollins-Sussman、BrianW.Fitzpatrick和C.MichaelPilato1基本概念1.1版本库Subversion是一个“集中式”的信息共享系统。版本库是Subversion的核心部分，是数据的中央仓库。版本库以典型的文件和目录结构形式文件系统树来保存信息。任意数量的客户端连接到Subversion版本库，读取、修改这些文件。客户端通过写数据将信息分享给其他人，通过读取数据获取别人共享的信息。Subversion的版本库是一种文件服务器，但不是“一般”的文件服务器。Subversion版本库的特别之处在于，它会记录每一次改变：每个文件的改变，甚至是目录树本身的改变，例如文件和目录的添加、删除和重新组织。1.2版本模型一个版本控制系统的核心任务是能够合作编辑和分享数据。而不同系统用不同策略实现这一点。1.2.1“锁定-修改-解锁”方案这种模型，版本库一次只允许一个用户修改某个文件。这种独占的策略使用锁来管理。即每次修改前必须锁定这个文件。锁定-修改-解锁模型的问题是限制太多，经常会成为用户的障碍：•锁定可能导致管理问题。有时候Harry会锁住文件然后忘了此事，这就是说Sally一直等待解锁来编辑这些文件，她在这里僵住了。然后Harry去旅行了，现在Sally只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。•锁定可能导致不必要的线性化开发。如果Harry编辑一个文件的开始，Sally想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。•锁定可能导致错误的安全状态。假设Harry锁定和编辑一个文件A，同时Sally锁定并编辑文件B，如果A和B互相依赖，这种变化是必须同时作的，这样A和B不能正确的工作了，锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象Harry和Sally都以为自己锁住了文件，而且从一个安全，孤立的情况开始工作，因而没有尽早发现他们不匹配的修改。锁定经常成为真正交流的替代品。1.2.2“拷贝-修改-合并”方案Subversion，CVS和一些版本控制系统使用拷贝-修改-合并模型，在这种模型里，每一个客户联系项目版本库建立一个个人工作拷贝—版本库中文件和目录的本地映射。用户并行工作，修改各自的工作拷贝，最终，各个私有的拷贝合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。如果Sally和Harry的修改交迭了该怎么办？这种情况叫做冲突，这通常不是个大问题，当Harry告诉他的客户端去合并版本库的最新修改到自己的工作拷贝时，他的文件A就会处于冲突状态：他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦Harry手工的解决了冲突—也许需要与Sally讨论—它可以安全的把合并的文件保存到版本库。什么时候锁定是必需的？“拷贝-修改-合并”模型假定文件是可以上下文合并的——版本库中的大多数文件是基于行的文本文件。但是对于二进制文件，比如声音或图片等，通常不能合并修改。这种情况下，需要线性的修改。Subversion提供了这种机制。1.3Subversion版本库的URL正如我们在整本书里描述的，Subversion使用URL来识别Subversion版本库中的版本化资源，通常情况下，这些URL使用标准的语法，允许服务器名称和端口作为URL的一部分：$svncheckout…但是Subversion处理URL的一些细微的不同之处需要注意，例如，使用file:访问方法的URL(用来访问本地版本库)必须与习惯一致，可以包括一个localhost服务器名或者没有服务器名：$svncheckoutfile:///var/svn/repos…$svncheckoutfile://localhost/var/svn/repos…同样，在Windows平台下使用file://模式时需要使用一个非正式的“标准”语法来访问本机上不在同一个磁盘分区中的版本库。下面的任意一个URL路径语法都可以工作，其中的X表示版本库所在的磁盘分区：C:\svncheckoutfile:///X:/var/svn/repos…C:\svncheckoutfile:///X|/var/svn/repos…在第二个语法里，你需要使用引号包含整个URL，这样竖线字符才不会被解释为管道。当然，也要注意URL使用普通的斜线而不是Windows本地(不是URL)的反斜线。最后，必须注意Subversion的客户端会根据需要自动编码URL，这一点和一般的web浏览器一样，举个例子，如果一个URL包含了空格或是一个字符编码大于128的ASCII字符：$svncheckoutñaSubversion会避免不安全的字符并且转换为如下命令:$svncheckout当URL包含空格时，必须用双引号括起来，这样你的shell才会把它们当做一个完整的参数表1.1.版本库访问URL模式访问方法file:///直接版本库访问(本地磁盘)http://通过配置Subversion的Apache服务器的WebDAV协议https://与http://相似，但是包括SSL加密。svn://通过svnserve服务自定义的协议svn+ssh://与svn://相似，但通过SSH封装。1.4工作拷贝Subversion工作拷贝是你本地机器上的一个普通目录，保存着一些文件，你可以任意的编辑文件，而且如果是源代码文件，你可以像平常一样编译，你的工作拷贝是你的私有工作区，在你明确的做了特定操作之前，Subversion不会把你的修改与其他人的合并，也不会把你的修改展示给别人，你甚至可以拥有同一个项目的多个工作拷贝。当你在工作拷贝作了一些修改并且确认它们工作正常之后，Subversion提供了一个命令可以“发布”你的修改给项目中的其他人(通过写到版本库)，如果别人发布了各自的修改，Subversion提供了手段可以把这些修改与你的工作目录进行合并(通过读取版本库)。工作副本也包括一些由Subversion创建并维护的额外文件，用来协助执行命令。通常情况下，你的工作副本的每个文件夹都有一个以.svn为名的文件夹，也被叫做工作副本的管理目录，这个目录里的文件能够帮助Subversion识别哪些文件做过修改，哪些文件相对于别人的工作已经过期。一个典型的Subversion的版本库经常包含许多项目的文件(或者说源代码)，通常每一个项目都是版本库的子目录，在这种布局下，一个用户的工作拷贝往往对应版本库的的一个子目录。举一个例子，你的版本库包含两个软件项目，paint和calc。每个项目在它们各自的顶级子目录下。为了得到一个工作拷贝，你必须检出(checkout)版本库的一个子树，(术语“checkout”听起来像是锁定或者保留资源，实际上不是，只是简单的得到一个项目的私有拷贝)，举个例子，你检出/calc，你可以得到这样的工作拷贝：$svncheckout列表中的A表示Subversion增加了一些条目到工作拷贝，你现在有了一个/calc的个人拷贝，有一个附加的目录—.svn—保存着前面提及的Subversion需要的额外信息。假定你修改了button.c，因为.svn目录记录着文件的修改日期和原始内容，Subversion可以告诉你已经修改了文件，然而，在你明确告诉它之前，Subversion不会将你的改变公开，将改变公开的操作被叫做提交(committing，或者是checkingin)修改到版本库。将你的修改发布给其他人，你可以使用Subversion的svncommit:$svncommitbutton.c-mFixedatypoinbutton.c.Sendingbutton.cTransmittingfiledata.Committedrevision57.现在你对button.c的修改已经被提交到版本库,并用一个注释描述了你的修改(即：fixedatypo).如果另一个用户检出（checksout）/calc的工作拷贝,他会在这个文件的最新版本中看到你的修改。假设你有个合作者，Sally，她和你同时取出了/calc的一个工作拷贝，你提交了你对button.c的修改，Sally的工作拷贝并没有改变，Subversion只在用户要求的时候才改变工作拷贝。为保持她的项目最新,Sally会要求Subversion更新她的工作拷贝,通过使用svnupdate.这会将你的修改与她的工作拷贝合并,其中也包括（自她上次更新后）其他人提交的修改。$pwd/home/sally/calc$ls-A.svn/Makefileinteger.cbutton.c$svnupdateUbutton.cUpdatedtorevision57.svnupdate命令的输出表明Subversion更新了button.c的内容，注意，Sally不必指定要更新的文件，subversion利用.svn以及版本库的进一步信息决定哪些文件需要更新。1.5修订版本一次svncommit操作发布的对任何数目文件和目录的修改被作为一个原子处理。在你的工作拷贝中，你可以修改文件的内容，创建、删除、重命名、拷贝文件和目录，然后将这一系列修改提交作为一次原子处理。对于原子处理，我们的意思是:要么这所有修改都在版本库中发生,要么一个也不发生。Subversion面对程序崩溃、系统崩溃、网络问题和其他用户的操作时尽量维持这种原子性。每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做一次修订(revision)，每一个修订版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是0，只创建了一个空目录，没有任何内容。全局版本号不像大多数的版本控制系统，Subversion's修订号是对于整个目录树而言的,而不是单独的文件。每个修订号代表整个目录树，在某些已提交修改后版本库的一个特点状态。另一种理解方式是修订N代表版本库文件系统在第N次提交后的状态。图1.7“版本库”可以更形象的描述版本库，想象有一组修订号，从0开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库“快照”。需要特别注意的是，工作拷贝并不一定对应版本库中的单个修订版本，他们可能包含多个修订版本的文件。举个例子，你从版本库检出一个工作拷贝，最近的修订号是4：calc/Makefile:4integer.c:4button.c:4此刻，工作目录与版本库的修订版本4完全对应，然而，你修改了button.c并且提交之后，假设没有别的提交出现，你的提交会在版本库建立修订版本5，你的工作拷贝会是这个样子的：calc/Makefile:4integer.c:4button.c:5假设在这个时候,Sally提交了对integer.c的修改,创建了修订6.如果你使用svnupdate更新你的工作拷贝,它就会像这样:calc/Makefile:6integer.c:6button.c:6Sally对integer.c的改变会出现在你的工作拷贝，你对butto