文档规则[本地工作区] ：work copy，本地工作副本；[主项目]：引用共用模块的新项目（工程）最新版本（HEAD revision）：版本库里文件或目录的最新版本SA ：SVN服务器的管理员PRA ：单个项目库的管理员，或者是项目负责人User ：普通工作人员WC ：work copy ，本地工作副本一、模块化开发中svn的使用主要介绍模块化开发中公用模块/组件的版本控制，介绍两种方法。
其中，公用模块一般指那些已经完成的、不可修改的、无法编译成dll的、功能较为完整的代码群。
1.1手工维护公用模块/组件的[本地工作区]将公用模块（的所需版本）直接取出ckeckout 到本地，公用模块的[本地工作区] 可以作为被引用的[主项目] [本地工作区] 的子目录也可以放在其他独立目录中。
[主项目]的提交commit 对公用模块的[本地工作区] 不会发生任何影响，而且公用模块的[本地工作区] 需要项目团队中的每个成员与[主项目] [本地工作区] 相对独立的维护（取出ckeckout ），可能会出现不同项目成员之间的公用模块[本地工作区] 不一致的错误。
1.2 Svn自动维护公用模块/组件的[本地工作区]需要使用svn:externals属性，具体操作步骤如下：察看[主项目] [本地工作区] 的目录属性添加svn:externals 属性，格式：子目录名称-r版本号公用模块的URL。
公用模块取出ckeckout出来的[本地工作区] 必须作为[主项目][本地工作区] 的子目录，格式中的“子目录名称”就是指公用模块的[本地工作区] 目录名称，注意不要与[主项目]自身的目录同名。
如果需要使用公用模块的特殊版本，需要设置格式中的“版本号”，注意加上“-r”。
设定好svn:externals属性后需要进行提交commit操作。
项目团队的其他成员直接更新update即可，能够自动得到公用模块的[本地工作区]。
[主项目]的提交commit对公用模块的[本地工作区] 不会发生任何影响。
如果引用多个模块，只需要在设置该属性值的时候将多个模块的路径都填写上去即可。
注意：公用模块的[本地工作区] 一般不建议进行修改，即不要直接对公用模块的[本地工作区] 进行修改、提交commit 操作，建议管理员将公用模块的svn库的权限设置设定为只读权限。
如果公用模块确实需要针对[主项目]进行个性化修改，这种情况的处理方法在此次讲座的后面将会谈到。
二、分支技术与产品化开发2.1 tag/branch的作用和区别分支:常用来测试新功能，但又不会因为编译错误或BUG干扰开发主线。
标记:用来对项目的特殊版本进行标记，通常不再用于开发。
当然你也可以修改/tags/中的副本，但提交时SVN会有警告。
例如当项目达到发行状态时可以创建一个发行版本的标记。
注意：/trunk /branches /tags 是SVN默认的主干/分支/标记目录的名称，SVN将对这三个目录有特殊的处理。
2.2推荐的版本库结构：一个项目建立一个版本库，trunk目录来存放开发的“主线”，branches 目录来存放支线副本，tags目录来存放标签副本。
具体结构如下Project_XXX../trunk../branches../tags●Trunk目录保存开发的“主线”，保存项目日常开发过程中代码和文档的各个过程版本，一般建议Trunk目录下面至少包含两个目录：Document、Source、Product，分别保存文档、程序源码、交付用户的安装包及手册。
●branches目录来存放支线副本，建议branches目录下至少包含两个目录：Alpha和Special，分别保存测试分支和定制化开发项目分支。
创建分支时分支的名称要尽量能够表明分支的用途，例如一个测试分支名为FirstTest20070601，其目录为Project_XXX/tags/Alpha/FirstTest20070601。
使用支线的的常用模式为：1、项目达到可测试状态准备交给测试团队进行测试，创建Trunk的测试分支保存至Alpha目录下，测试团队从这个测试分支获取安装包或者程序等进行测试；2、项目要根据另外一个新客户进行少量定制化开发，为了避免干扰目前项目的开发，创建Trunk的定制化开发分支保存至Special目录下。
●tags目录来存放标签副本，以方便查找某些重要项目版本。
建议目录下至少包含两个目录：Release和Other，分别保存产品发布标签和其他标签。
使用标签的常用模式为：1、当Alpha分支经过严格测试达到发布标准后，将Alpha的最新版本做Tag保存在Release目录中；2、重要里程碑阶段进行Tag保存在Other目录。
2.3如何做branch2.3.1分支—>主干实施团队开始为某个单位进行实施前，首先通过配置管理委员会的评审来建立相应实施模块的分支。
需要对该单位实施多少个模块，就要针对多少个模块分别建立分支，分支的名称建议采用“项目名+时间”的形式，下图显示的为source 模块所建立的XXX厂的分支：选择“切换工作拷贝到新分支/标记的选项”时，本地工作区将变成新建分支的副本。
一般来说，这个分支是不是由实施团队建立的，操作人员没必要马上将自己的工作区变成分支的副本。
需要变成分支副本时，可以还可以通过切换Switch...命令完成转变工作。
切换Switch...操作时一定要注意目录的对应关系，即切换后目录的项目意义不能发生更改，在trun k主干上是class目录切换分支后不能是别的目录。
进行改操作之前必须提交commit [本地工作区]，并尽量在[本地工作区]的根目录上进行改操作。
2.4实施团队版本控制工作内容2.4.1建立实施项目的版本库参照“2.2 推荐的版本库结构”中介绍的方式组织版本库，经配置管理委员会评审并建立该实施项目的版本库。
2.4.2组织本地工作区项目实施负责人首次取出checkout 新建分支后，按照Svn自动维护公用模块/组件的[本地工作区] 将soruce 目录的svn:externals属性进行设置，然后提交供实施团队中其他人员下载（取出checkout或者更新update）。
如果引用的模块（子系统）需要个性化修改，可以由配置管理委员会将该模块（子系统）所实施项目的分支权限设置为可编辑模式，项目实施团队对该分支进行修改、提交操作。
2.5 brach合并2.5.1分支——〉主干实施团队在分支上的工作过程中发现一个在主干trunk上也同样存在的错误，实施团队在自己的分支上修改并提交commit后需要通知配置管理委员会，以便开发团队和其他项目团队能够更改这个共同的错误。
下图显示分支将错误修改的工作内容合并到主干trunk上的过程，其操作人员为开发团队成员：确定[本地工作区] 是主干trunk后，点击鼠标右键，选择“合并Merge...”命令：起始和结束地址对应的目录必须与“对应版本库URL”所指的目录在项目意义上是相同的，即必须都为class目录或者都为bin目录。
起始版本到结束版本之间的所有增加Add、重命名Rename、移动、删除、修改等等操作都将合并到主干trun k上。
在“合并”前先进行“比较差异”或者“预检”来确定上面的选项填写的是否正确无误。
“比较差异”使用差异比较工具分别显示主干和分支的内容，以方便对比差异。
“预检”使用svn内置的合并工具进行试验性质的合并（不是实际的合并），以检测是否能够自动合并。
“合并”后，trunk的[本地工作区] 将发生变化，即将分支上的修改内容加到了主干trunk上，开发团队需要进行提交commit，提交时建议在注释中填写合并的范围信息，以便下次合并时避免进行重复的合并，即下次合并时从这次合并的范围之后开始合并。
2.5.2合并——〉分支基本过程与上面的相同，但是改成在实施团队的[本地工作区] 上进行操作。
注意：无论是何种方向的合并，都要注意合并的周期，不能间隔过长的时间，否则分支/主干的变化过多时合并操作将非常困难。
当然，项目的个性化开发所做的分支修改可以不必合并到主干上。
合并的实质就是将其他分支上的变化过程更新到自己的[本地工作区] 上，就像我们用开发工具直接修改[本地工作区] 一样，只不过合并提供了一个自动化的手段（不完全的自动化），如果需要合并的文件很少而且你比较清楚是那些差异，完全可以自己修改[本地工作区] 然后直接提交。
另外，对于二进制文件由于无法进行差异比较，其合并更多的就是将旧文件删掉使用新文件。
2.6如何做tag标签的建立过程跟分支建立完全一样，只是目录不同：如果一个已经标记过的还发布了的版本Version_1.0.0（开发团队可能已经正在进行2.0版的开发了），还要进行修改，正确的方法是创建一个新的分支，在新分支上做修改，再根据这个分支创建新标记，比如Version_1.0.1，然后把这个新分支版本提供给用户。
三、一些小技巧3.1建立版本库的桌面快捷方式在桌面上建立一个任意程序的快捷方式，然后将快捷方式的“目标”修改成类似下例中的内容："C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:repobrowser /path:svn://localhost/Pro01 /notempfile其中蓝色部分是项目的在svn服务器上的路径地址。
3.2几种不同的忽略处理方式3.2.1全局忽略模式这种方式影响本机的所有项目，不影响其他团队成员（在其各自的客户端操作）的操作。
3.2.2添加到忽略列表选中该文件，使用右键中的“添加到忽略列表”命令，仅是对当前[本地工作区]有效，不影响本机其他[本地工作区]3.2.3 svn:ignore属性该方式仅影响所选项目/项目目录的，团队其他成员也受影响。
3.3忽略被错误加入进版本库中的文件1.本应该忽略的文件刚被“Add（添加）”进版本库，还未“Commit（提交）”。
选中该文件，然后使用右键中的“Svn还原”命令来取消刚才的“Add（添加）”的操作；然后再选用适当的忽略处理方式将该文档忽略。
选中该文件，使用右键中的“添加到忽略列表”命令，将其添加到忽略列表中避免以后犯同样的错误。
2.本应该忽略的文件刚被“Add（添加）”进版本库，并进行了“Commit（提交）”。
需要下面几个步骤来进行操作：1.将这个文件移动到别的目录中（一定不是这个项目的[本地工作区]）；2.进行“Commit（提交）”操作，出现下图所示界面，选中该文件前的复选框，然后“确定”。
3.把刚才移出去的文件再次移回来，然后再选用适当的忽略处理方式将该文档忽略。
3.4多项目共享认证修改conf文件夹中的svnserver.conf文件下列选项：●password-db ：“定义用户口令”的文件所在地址的设置项为了达到共享认证的目标多个项目的password-db的设置所对应的口令文件必须相同。
