Subversion中文使用指南

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

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

1 / 24
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功