Subversion中文使用指南.docxVIP

Subversion使用指南主要的参考资料是《Subversion 权威指南: 针对 Subversion 1.6: (编译自 r3600/r3578)》Ben Collins-Sussman、Brian W. Fitzpatrick和C. Michael Pilato1 基本概念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.3 Subversion 版本库的 URL正如我们在整本书里描述的，Subversion使用URL来识别Subversion版本库中的版本化资源，通常情况下，这些URL使用标准的语法，允许服务器名称和端口作为URL的一部分：$ svn checkout :9834/repos…但是Subversion处理URL的一些细微的不同之处需要注意，例如，使用file:访问方法的URL(用来访问本地版本库)必须与习惯一致，可以包括一个localhost服务器名或者没有服务器名：$ svn checkout file:///var/svn/repos…$ svn checkout file://localhost/var/svn/repos…同样，在Windows平台下使用file://模式时需要使用一个非正式的“标准”语法来访问本机上不在同一个磁盘分区中的版本库。下面的任意一个URL路径语法都可以工作，其中的X表示版本库所在的磁盘分区：C:\ svn checkout file:///X:/var/svn/repos…C:\ svn checkout file:///X|/var/svn/repos…在第二个语法里，你需要使用引号包含整个URL，这样竖线字符才不会被解释