SVN架构组件及版本控制使用指南
SVN架构组件及版本控制使用指南
摘 要：
svn(subversion)是目前主流的版本控制工具。目前，绝大多数开源软件都使用svn作为代码版本管理软件。svn支持unix、window等平台，同时包括stand-only、Apache两种运行方式，可以跨接Internet, Intranet, Extranet间的网络所有端点??本文档主要关注SVN在版本控制、分支管理及版本发布更新，以期在实际工作中能够灵活、方便的对产品、基线及更新进行控制及管理，同时对SVN的整体架构和安全领域进行简要介绍，最后对SVN自动化备份及使用技巧进行说明。
关键词：svn; 版本; 控制; 备份;安全
一、 SVN介绍及架构
2
SVN (subversion)是近年来崛起的版本管理工具，是cvs的接班人。目前，绝大多数开源软件都使用SVN作为代码版本管理软件。本文旨在介绍SVN的版本控制及分支、合并管理，同时对SVN的日常维护行为进行说明。
SVN具有高效、版本追溯功能强大、跨平台等功能，比CVS更适合进行版本管理和配置管理工作。CVS纵然是一个老牌的工具产品，并也对开源事业有贡献，但CVS的命令行操作着实让一些使用者头疼。在对一个特定版本的文档Check in的时候，需要输入一长串的路径名、文件名。在操作易用性上与CVS形成对比的是微软家族的VSS。作为微软的产品，在图形界面化操作上自不用多言，但VSS只能适用于小团队的开发工作。VSS是很好的入门级工具，但它的一些功能太过于“入门”，在验证密码、保存密码这些基本功能上处理的不尽人意。适用于大型软件开发的有“中坚级”的Clearcase，用它来管理一些小型的项目管理有些“大材小用”。Clearcase支持目录版本管理、异地团队开发、视图、多服务器等强大功能，所以一些大公司把它做为一、二级产品管理用，但同样它的价格也不菲。CVS是开源的，免费的，更何况它还有一个理想的替代者——SVN。SVN的设计专门针对CVS的问题作了改进,命令的设计更为合理,对二进制文档和目录这样的数据加强了控制能力,并且吸收了VSS的lock-modify-update(release)的模式和modify-merge模式的优点这两种方式在一定程度都支持并作了优化,没有提高使用的复杂度。由于SVN的设计结构很好,所以很容易为它开发客户端,还有WEB模式的,可以远程管理,支持RSS更改订阅。
需要注意的是，SVN只是一个工具，它提供了简单的配置管理操作手段，但是一个好的配置管理是依托于配置管理流程以及对应流程控制软件的，这在下面也会说明。没有项目管理流程以及配置管理流程控制的SVN只会导致最终的混乱，每一个软件都无法摆脱这种魔咒，何况SVN目前仍存在很多无法很好解决的问题，具体可以参见http://tortoisesvn.net/。
以下从SVN的架构开始本文。
3
Commandline client appGUI Client appsClient InterfaceWorking Copy Management LibraryClient LibraryRepository AccessDAV SVN LocalAny TCP/IP Network(DAV)ApacheMod_davMod_dav_svn(SVN)SVN ServerRepositoryInterfaceSVN RepositoryBerkeley DBFSFS 图 1
图中的一端是保存所有在版本控制下数据的SVN版本库，另一端是SVN的客户端程序，管理着所有在版本控制下数据的本地映射（称为工作拷贝），在这两端之间是各种各样的版本库访问（Repository Access）层，某些使用电脑网络通过网络服务器访问版本库，某些则绕过网络服务器直接访问版本库。 SVN客户端可以通过命令行进行操作，或者使用SVN的图形界面客户端进行SVN检出、更新、提交及分支等操作。
SVN可以通过Stand-only方式直接访问版本库，或者通过tcp/ip协议访问配置库。
SVN版本库存在两种数据存储方式，即BDB(Berkeley DB)方式及FSFS方式。BDB方式提供事务支持，可以进行热备份，同时支持事务回滚。但是BDB方式无法跨平台使用，不支持window95及windows98(虽然这两个版本目前已经很少使用)，且无法放置网络共享文件夹中。而FSFS方式不需要数据库存储系统支持，且在系统崩溃后仍能继续使用。鉴于SVN对数据存储年限可能较长，同时未来环境因素无法考量，故推荐使用FSFS存储方式。
了解SVN的主体架构可以更迅速的理解第三部分关于SVN安全的介绍，同时能够使用户对日常所遇见问题进行快速定位；熟悉SVN的实现方式后还能为下一步更进一步的使用或二次开发提供基础。
二、 SVN分支介绍及使用（包括分支目录与目录合并，以及标签建立）
0. 准备
假设本地SVN检出目录为SVNTest，其中包括三个目录——trunk、branches和tags：
4
图 2
其中trunk为主工作目录，branches为分支目录，tags为标签目录。这三个目录的作用会在后面进行介绍。目前trunk主目录中维护了本地的代码库和文档库——code和document：
图 3
1. 分支介绍
假设目前已经建立一个稳定的版本库，此时另外一个部门需要你提供该配置库所维护产品的一个副本，然后这个副本与目前的配置库有些许细小差别。这种情况下该怎么做？
做简单的方法就是做这个版本的拷贝，然后分别维护两个版本；同时你还需要同时维护这两个版本的大部分相同的文件，使得主路径文件发生变化后，拷贝版本的对应文件也能同时产生正确更新。这时，最原始的分支就已经产生了。
分支常用来测试新功能，但又不会因为编译错误或BUG干扰开发主线。本文示例配置库中branches为分支目录。
标记通常作为一个稳定的版本进行维护，在建立标记之后，通常不对标记进行更新和维护，标记库通常作为一个基线或者稳定版本进行管理，示例库中tags对标记库进行维护。 2. SVN实现分支控制
前置条件：目前主工作目录trunk中code目录下代码已完成一轮迭代测试并修改完毕。此时需要在此基础上增加新的功能，同时原来的版本需要保证正常使用。此时需要为code目录建立分支开发全新的功能，同时在主目录下进行后续的迭代测试后，正确的代码也需要维护入分支。 首先，我们需要为code目录建立分支： 右键点击该文件，选择Branch/tags
