《SVN操作规范与指南》.docxVIP

SVN操作规范与指南（产品研发部）编写： 王卓譞2011 年 6 月 8 日校对： 年 月 日审核： 年 月 日标审： 年 月 日批准： 年 月 日北京阳光伟业科技发展有限公司修订记录日期修订版本描述作者2011年6月8日1.0初稿完成王卓譞2011年6月22日1.1新增2.5节AnkhSVN王卓譞分发记录Copy No.持有者和角色分发日期目录1SVN操作指南51.1版本控制基本概念51.1.1版本库51.1.2版本模型51.1.3工作副本81.1.4版本库的URL91.1.5修订版本91.1.6工作副本怎样跟踪版本库101.2使用指南111.2.1图示111.2.2检出111.2.3提交更改131.2.4解决冲突142全局规范152.1软件环境152.2证书安装152.3TortoiseSVN的安装与设置192.4Subclipse安装与设置212.5AnkhSVN安装与使用222.6密码修改232.7访问地址232.8版本库列表及其用途233部门库规范253.1目录规范253.2权限分配原则264产品库规范274.1目录规范274.2权限分配原则275项目库规范285.1目录规范285.2权限分配原则296实施库296.1目录规范296.2权限分配原则307代码库317.1目录规范317.2权限分配原则317.3内容规范317.4操作规范31SVN操作指南版本控制基本概念版本库Subversion是一种集中的分享信息的系统，它的核心是版本库，储存所有的数据，版本库按照文件树形式储存数据－包括文件和目录，任意数量的客户端可以连接到版本库，读写这些文件。通过写数据，别人可以看到这些信息；通过读数据，可以看到别人的修改。版本库是另一种文件服务器，而不是你常见的那一种。最特别的是Subversion会记录每一次的更改，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录。版本模型所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？版本库里意外覆盖别人的更改非常的容易。考虑这个情景，我们有两个共同工作者，Harry 和 Sally，他们想同时编辑版本库里的同一个文件，如果首先 Harry 保存它的修改，过了一会，Sally 可能凑巧用自己的版本覆盖了这些文件，Harry 的更改不会永远消失(因为系统记录了每次修改)，Harry 所有的修改不会出现在 Sally 的文件中，所以 Harry 的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的，这就是我们要明确避免的情况。锁定-修改-解锁 方案锁定-修改-解锁模型有一点问题就是限制太多，经常会成为用户的障碍: 锁定可能导致管理问题。有时候 Harry 会锁住文件然后忘了此事，这就是说 Sally 一直等待解锁来编辑这些文件，她在这里僵住了。然后 Harry 去旅行了，现在 Sally 只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。锁定可能导致不必要的线性化开发。如果 Harry 编辑一个文件的开始，Sally 想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。锁定可能导致错误的安全状态。假设 Harry 锁定和编辑一个文件 A，同时 Sally 锁定并编辑文件 B，如果 A 和 B 互相依赖，这种变化是必须同时作的，这样 A 和 B 不能正确的工作了，锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象 Harry 和 Sally 都以为自己锁住了文件，而且从一个安全，孤立的情况开始工作，因而没有尽早发现他们不匹配的修改。复制-修改-合并 方案Subversion，CVS 和一些版本控制系统使用复制-修改-合并模型，在这种模型里，每一个客户读取项目版本库建立一个私有工作副本—版本库中文件和目录的本地映射。用户并行工作，修改各自的工作副本，最终，各个私有的复制合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。但是如果 Sally 和 Harry 的修改重叠了该怎么办？这种情况叫做冲突，这通常不是个大问题，当 Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件 A 就会处于冲突状态: 他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并做出智能的选择，一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论)，他就可以安全的把合并的文件保存到版本库。复制-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个