SVN架构组件及版本控制使用指南.docx

SVN架构组件及版本控制使用指南.docx

《SVN架构组件及版本控制使用指南.docx》由会员分享，可在线阅读，更多相关《SVN架构组件及版本控制使用指南.docx（16页珍藏版）》请在冰豆网上搜索。

SVN架构组件及版本控制使用指南

SVN架构组件及版本控制使用指南

摘要：

svn（subversion）是目前主流的版本控制工具。

目前，绝大多数开源软件都使用svn作为代码版本管理软件。

svn支持unix、window等平台，同时包括stand-only、Apache两种运行方式，可以跨接Internet,Intranet,Extranet间的网络所有端点……本文档主要关注SVN在版本控制、分支管理及版本发布更新，以期在实际工作中能够灵活、方便的对产品、基线及更新进行控制及管理，同时对SVN的整体架构和安全领域进行简要介绍，最后对SVN自动化备份及使用技巧进行说明。

关键词：

svn;版本;控制;备份;安全

一、SVN介绍及架构

SVN（subversion）是近年来崛起的版本管理工具，是cvs的接班人。

目前，绝大多数开源软件都使用SVN作为代码版本管理软件。

本文旨在介绍SVN的版本控制及分支、合并管理，同时对SVN的日常维护行为进行说明。

SVN具有高效、版本追溯功能强大、跨平台等功能，比CVS更适合进行版本管理和配置管理工作。

CVS纵然是一个老牌的工具产品，并也对开源事业有贡献，但CVS的命令行操作着实让一些使用者头疼。

在对一个特定版本的文档Checkin的时候，需要输入一长串的路径名、文件名。

在操作易用性上与CVS形成对比的是微软家族的VSS。

作为微软的产品，在图形界面化操作上自不用多言，但VSS只能适用于小团队的开发工作。

VSS是很好的入门级工具，但它的一些功能太过于“入门”，在验证密码、保存密码这些基本功能上处理的不尽人意。

适用于大型软件开发的有“中坚级”的Clearcase，用它来管理一些小型的项目管理有些“大材小用”。

Clearcase支持目录版本管理、异地团队开发、视图、多服务器等强大功能，所以一些大公司把它做为一、二级产品管理用，但同样它的价格也不菲。

CVS是开源的，免费的，更何况它还有一个理想的替代者——SVN。

SVN的设计专门针对CVS的问题作了改进,命令的设计更为合理,对二进制文档和目录这样的数据加强了控制能力,并且吸收了VSS的lock-modify-update（release）的模式和modify-merge模式的优点这两种方式在一定程度都支持并作了优化,没有提高使用的复杂度。

由于SVN的设计结构很好,所以很容易为它开发客户端,还有WEB模式的,可以远程管理,支持RSS更改订阅。

需要注意的是，SVN只是一个工具，它提供了简单的配置管理操作手段，但是一个好的配置管理是依托于配置管理流程以及对应流程控制软件的，这在下面也会说明。

没有项目管理流程以及配置管理流程控制的SVN只会导致最终的混乱，每一个软件都无法摆脱这种魔咒，何况SVN目前仍存在很多无法很好解决的问题，具体可以参见

以下从SVN的架构开始本文。

图1

图中的一端是保存所有在版本控制下数据的SVN版本库，另一端是SVN的客户端程序，管理着所有在版本控制下数据的本地映射（称为工作拷贝），在这两端之间是各种各样的版本库访问（RepositoryAccess）层，某些使用电脑网络通过网络服务器访问版本库，某些则绕过网络服务器直接访问版本库。

SVN客户端可以通过命令行进行操作，或者使用SVN的图形界面客户端进行SVN检出、更新、提交及分支等操作。

SVN可以通过Stand-only方式直接访问版本库，或者通过tcp/ip协议访问配置库。

SVN版本库存在两种数据存储方式，即BDB（BerkeleyDB）方式及FSFS方式。

BDB方式提供事务支持，可以进行热备份，同时支持事务回滚。

但是BDB方式无法跨平台使用，不支持window95及windows98（虽然这两个版本目前已经很少使用），且无法放置网络共享文件夹中。

而FSFS方式不需要数据库存储系统支持，且在系统崩溃后仍能继续使用。

鉴于SVN对数据存储年限可能较长，同时未来环境因素无法考量，故推荐使用FSFS存储方式。

了解SVN的主体架构可以更迅速的理解第三部分关于SVN安全的介绍，同时能够使用户对日常所遇见问题进行快速定位；熟悉SVN的实现方式后还能为下一步更进一步的使用或二次开发提供基础。

二、SVN分支介绍及使用（包括分支目录与目录合并，以及标签建立）

1.准备

假设本地SVN检出目录为SVNTest，其中包括三个目录——trunk、branches和tags：

图2

其中trunk为主工作目录，branches为分支目录，tags为标签目录。

这三个目录的作用会在后面进行介绍。

目前trunk主目录中维护了本地的代码库和文档库——code和document：

图3

2.分支介绍

假设目前已经建立一个稳定的版本库，此时另外一个部门需要你提供该配置库所维护产品的一个副本，然后这个副本与目前的配置库有些许细小差别。

这种情况下该怎么做？

做简单的方法就是做这个版本的拷贝，然后分别维护两个版本；同时你还需要同时维护这两个版本的大部分相同的文件，使得主路径文件发生变化后，拷贝版本的对应文件也能同时产生正确更新。

这时，最原始的分支就已经产生了。

分支常用来测试新功能，但又不会因为编译错误或BUG干扰开发主线。

本文示例配置库中branches为分支目录。

标记通常作为一个稳定的版本进行维护，在建立标记之后，通常不对标记进行更新和维护，标记库通常作为一个基线或者稳定版本进行管理，示例库中tags对标记库进行维护。

3.SVN实现分支控制

前置条件：

目前主工作目录trunk中code目录下代码已完成一轮迭代测试并修改完毕。

此时需要在此基础上增加新的功能，同时原来的版本需要保证正常使用。

此时需要为code目录建立分支开发全新的功能，同时在主目录下进行后续的迭代测试后，正确的代码也需要维护入分支。

首先，我们需要为code目录建立分支：

右键点击该文件，选择Branch/tags

图4

选择分支种类，主要分为工作拷贝（workingcopy）方式和知识库（repository）方式，两种方式在使用中没有很大差异，只是在分支维护方式上有差异，一般选择工作拷贝方式，简单不容易因为网络问题而出现冲突。

次数选择工作拷贝方式。

ToUrl选择分支所在路径：

图5

点击ok后可以看到在/branches/my_test_copy_branches路径下产生测试分支——myBran1。

到此为止分支创建完毕。

此时在主工作库中维护更新后，在trunk中我们创建的分支也可以进行相应的更新，同时在分支中我们还可以维护自己的与主工作库中不同的文件。

目前我们已经有了我们的分支，这时分支目录的新功能已经添加完毕，现在要求将该新功能维护入主工作库，这是我们就需要进行分之合并。

目前分支合并只适合差异文件不多的情况下，最好是一个新的目录，与主工作库没有文件关联，否则合并时就要选择冲突处理方式，会产生与期望相悖的结果。

现在我们将我们刚才创建的分支bran1合并到刚才的主工作库，右键点击merge：

图6

下面出现三个选项，可以选择所需要合并的版本，或者按照最新版本合并，或者将不同的分支进行合并。

我们选择按照版本合并：

图7

下面选择需要合并的分支以及需要合并的版本：

图8

下面选择合并规则：

图9

之后是冲突解决方式，当冲突出现时我们可以选择以本地版本为标准，或者以目标版本为标准，或者保存冲突，之后自己维护：

图10

至此版本合并完成，可以看到主工作库中已经融入了分支中的文件。

在这里简要介绍一下branch与switch，建立分支之后可以对分支进行更新操作，而switch则是维护本地文件的一个镜像备份，一般在分支上维护一个新的分支可以考虑使用switch。

4.SVN实现标签控制

我们的tags目录下存放的是标签库。

标签库维护的是一些不会改变的文件及数据，比如建立基线或者版本的时候，可以将完成的基线版本或者产品版本维护在标签库中。

标签库其实是一种特殊的分支，其实现方式与创建分支的过程一样，只是在维护中不进行合并、更新等操作，只是一个最简单的拷贝。

5.版本控制原则

以上介绍了版本控制的基本方法，然而实际过程中版本控制需要依托于管理，不管是管理流程还是管理系统，都是真正的版本控制精髓。

SVN（或者其他版本控制软件）只是一个版本控制的辅助工具，不可能把所有的问题都自动解决掉。

尤其，对于冲突这个麻烦事儿，项目成员在项目进程中要尽量通过优化流程来解决，而不是将希望寄托于软件工具来自动解决一切问题。

下面对于开发过程提出以下两点建议：

（1）随行就市

项目刚开始阶段，单独开发；项目稳定阶段，完整开发。

项目开发初期，各个项目成员负责自己的文件夹（或者模块），与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹（或者模块）就行了，他人的文件夹（或者模块）可以不必关心；项目稳定阶段，也就是每天的变更量很小了，所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹（或者模块），各个项目成员在其本地编译时本地工作区的全部项目程序（或者资料）均为最新的版本，保证项目作为整体能够顺利运行。

（2）能躲就躲

尽量保证一份文件只有一个项目成员在编辑。

举例说明：

程序员A负责底层中文件DBAccess.cs的编写，如果程序员B的工作要求他为DBAccess.cs增加两个方法，程序员B应该通知程序员A来增加而不是自己增加；如果此时A非常繁忙需要B自己增加，就需要B先更新本地的DBAccess.cs，然后开始修改，修改完成后立即提交并通知A更新本地的文件，通过缩短提交间隔来减少冲突。

6.基于版本控制的开发原则

图11版本控制下的软件开发基本流程

注意：

上述的流程中没有考虑测试和审核的步骤。

三、SVN安全介绍

SVN安全可以从密码配置以及服务器等配置角度进行讲述。

密码配置主要是在配置文件中设置密码策略以及权限策略等。

下面主要从服务器架构方面简要介绍SVN安全策略。

一个SVN版本库可以和服务端同时运行于一个机器上，使用“file:

//”形式访问。

但是实际操作中，一个典型的SVN设置应该包含一个单独的服务器，可以被公司的所有客户端访问，甚至是全球客户端。

SVN包含一个抽象的网络层，这意味着版本库可以通过各种服务进程访问，而且客户端“版本库访问”的API允许程序员写出相关协议插件，理论上讲，SVN支持多种网络协议实现，目前实践中只有两种。

通过使用mod_dav_svn模块，利用Apache架设服务端，客户端使用HTTP的扩展协议WebDAV/DeltaV进行访问。

由于Apache是一个极易扩展的web服务器，因此可以使用SSL通讯、日志和第三方工具集成，以及内置的版本库Web浏览功能。

另一个是svnserver：

一个小而轻型的服务器程序。

该协议是SVN专门设计的，并且有状态，因此提供了更快的网络操作——代价则是它只理解CRAM-MD5认证。

这种方式非常易于配置，是小团队的最佳选择。

第三种选择则是使用SSH连接svnserver，这种部署方式使用SSH通讯加密方式，属于svnserver的一种变种。

对于一般的配置管理，使用svnserver部署方便而且速度快捷，但是没有很好的安全支持。

使用Apache方式构建服务端，可以提供多种方式的安全认证，比如SSL等，但是速度较慢。

而SSH方式的svnserver部署方式可以使用SSH通道加密方式，速度较快且部署简单，适于对安全有要求但是不是很高要求的场合。

四、自动化备份

目前SVN备份主要试用svnadmindump命令，简单易用。

但是实际备份过程中需要进行定期增量的和全亮的备份。

同时需要对备份文件进行压缩。

下面附上自动备份脚本（在windows下），使用时除了安装SVN外还需要安装winrar进行备份文件压缩。

五、使用技巧

1.建立版本库的桌面快捷方式

在桌面上建立一个任意程序的快捷方式，然后将快捷方式的“目标”修改成类似下例中的内容：

"C:

\ProgramFiles\TortoiseSVN\bin\TortoiseProc.exe"/command:

repobrowser/path:

svn:

//localhost/Pro01/notempfile

其中蓝色部分是项目的在svn服务器上的路径地址。

2.几种不同的忽略处理方式

——全局忽略模式

图12

这种方式影响本机的所有项目，不影响其他团队成员（在其各自的客户端操作）的操作。

——使用忽略列表

图13

选中该文件，使用右键中的“添加到忽略列表”命令，仅是对当前[本地工作区]有效，不影响本机其他[本地工作区。

——svn：

ignore属性

图14

该方式仅影响所选项目/项目目录的，团队其他成员也受影响。