版本管理工具SVN

I、前言

你是否正在参与团队合作项目？
你是否遇到过这样的情况：当你正在修改一个文件，却出现另一个人作了同样的事情。你是否曾因为这种巧合而导致了你的修改付之东流？
你是否曾经在文件保存之后，又想恢复到文件保存之前？你是否想过要去查看一个文件几天前的内容？
当你发现一个项目中的bug，你是否想知道它是何时出现在你的代码中？
如果你对上面任何一个问题回答“Yes”，那么TortoiseSVN就是你所需要的！你得仔细阅读TortoiseSVN的说明，学会如何解决上面的问题。这并不难～
这份说明是写给那些希望使用Subversion去管理他们的资料，却又不习惯于命令行的操作的人。因为TortoiseSVN就像是一个windows的扩展外壳，用户可以像使用“我的电脑”那样使用这个软件。
TortoiseSVN是自由软件，你不需要花钱就可以使用它，并且可以随意使用。它的开发遵循GPL协议。

以上是从TortoiseSVN的帮助文档摘录出来的。简单的说，TortoiseSVN可以看作一个代码版本控制工具，方便多人合作编写代码。现在有不少开源的作品是使用SVN作为源码管理工具的，学会了TortoiseSVN就可以很方便的拿到这些代码。
TortoiseSVN功能丰富，但是我们只需要学会2个简单的操作即可，第一就是下载代码，第二是上传。

 

II、比较

1、VSS和CVS

关键字:版本管理，SourceSafe，CVS，
本文主要对版本控制中SourceSafe和CVS的比较，描述出他们不同的特点和使用范围。
版本控制介绍
随着计算机应用范围的日益广泛深入，应用软件的规模及复杂程度日趋大型化、复杂化，这就导致软件开发的方式也从早期的单兵作战式或手工作坊式渐渐转变为集团化、工厂流水线式的团队协作开发方式。在这种开发模式中会遇到一些非常棘手的问题：
1．需要将整个软件版本恢复到以前的某一时间的状态。
2．控制某一程序在同一时间只能一个开发人员修改。
3．限制随意修改程序。
4．对每个开发人员编写的程序质量进行评估
．．．
版本管理系统则可以完美的解决以上问题。版本管理系统有很多。复杂而昂贵的ClearCase，性能良好的HanskyFirefly和目前最流行的VSS和CVS。
VSS和CVS介绍
VSS的全名是(VisualSourceSafe)，是微软公司开发的VisualStudio开发套件中的版本控制部分，你可以通过从微软购买全套的VisualStudio套件，单独购买SourceSafe来获得。因此SourceSafe拥有非常好的技术支持和非常详尽的技术文档。
CVS的全名是(ConcurrentVersionsSystem，并发版本系统)，它是一个开源项目，通过[url]http://www[/url]。cvshome。org/ 网站，你直接可以获取到最新的程序或者最新的源代码，因此CVS的使用是完全免费的。由于CVS仅可以在Unix平台下使用，在windows下出现了CVSNT([url]http://www[/url]。cvsnt。org/)服务器和WinCvs([url]http://www[/url]。guicvs。org/)客户端等开源产品
功能
u 文件修改方式
VSS主要采用独占模式(check_out，modify，check_in)，也可以使用(mutil_check_out，modify，check_in，merge)模式。在SourceSafe使用中独占模式使用的比较为成熟和普遍，独占模式要求每个人都必须在改动文件之前做捡出（check_out）标志，并且标志了后的文件无法被其他人修改，即文件被独占了，在完成了修改后要及时捡入（check_in），释放修改权。check_in和check_out也是人们对版本控制最开始的印象。
CVS采用了(update，modify，commit)工作方式。这是一种可以并发的版本控制方式，即每个人都可以修改自己可访问的任意代码，代码不会被一个人单独占用，两个人甚至多个人可以修改同一份代码，并且每个人的修改结果都不会被丢失。具体的操作过程为：在修改代码之前先做update，以使本地的代码最新，然后就可以修改代码了，修改完毕后，直接commit自己的修改结果。如果CVS没有发现冲突，则代码可以直接进入CVS资源库，否则，CVS则标出冲突的文件的冲突部分让你做合并。
u 文件历史
在这一点上VSS和CVS的功能都很近似，他们都可以保存了每个文件的变化历史，并提供了一个自动的版本号，随时可以取出任何文件的历史版本。并和当前版本做比较。都提供了自定义版本的label功能。检索历史和自定版本都非常的方便。VSS还特别提供了对时间段，或者操作人的历史操作查询，使一个人一段时间内对文件的操作一目了然。
u 项目版本管理
VSS并有直接对项目版本管理的支持，通过label来自定义一个版本号，可以解决部分项目版本管理的问题，但这是远远不够的，当一个产品根据用户需求产生一系列不同的项目版本时使用SourceSafe将非常难以管理。
CVS提供了比较完善的项目版本管理。CVS中可以把当前的工作定义成一个版本，一旦生成版本了则版本中的数据被单独取出，处于版本中的文件将保持只读，想获得一个项目的历史版本将轻而易举。同时，对于一个项目版本内部可以调整使用不同的文件版本。
u 分支功能。
CVS和VSS都提供了建立分支和合并分支的功能,但在操作中VSS首先要做项目共享,引入要分支的项目或文件然后做分支操作.CVS则是直接对文件或者项目做分支,分支操作同时建立。
开发集成
VSS可以和VisualStudio中的其他开发工具比如VB，VC++等做到直接集成，毕竟都是微软的产品么，同时由于VSS不光提供了图形界面也提供了命令行模式，所以在Windows操作系统中的大部分其他开发工具都提供了对VSS操作的集成，只要你安装了VSS的客户端。因此VSS在Windows平台下使用将会非常方便。
CVS本身是Unix系统上开发的，提供Unix上了命令行使用模式，因此和Unix上的vi、Emacs可以直接和CVS一起工作，至于Unix系统下的图形环境的开发工具比如eclipse,KDevelop和cvs集成都非常容易。本来在Windows平台上CVS的支持并不好，但近一段时间，随着WinCVS易用性越来越好，Windows下的部分开发工具已经提供了对WinCVS的支持，不过需要自己配置，而Windows下的Eclipse则直接集成了CVS，开发中可进行CVS操作。从而使Windows下CVS使用也越来越方便了。
操作界面和配置管理
VSS在Windows下提供了单独的客户端和服务器端操作界面，界面和windows操作系统风格一致，入门和使用都非常方便。即使被集成到别的开发工具中，它的使用界面也基本一样。通过工具SourceSafeAdmin，用户管理，权限管理，系统配置非常直观，基本不需要任何培训，直接看随程序自带的文档就可以准确使用。配置工具中包括了VSS数据的备份和恢复，系统自带文档相当详尽。
CVS的界面以命令行为主，在Unix平台下没有图形界面，部分图形的开发工具可能内嵌CVS客户端，在Windows平台下你可以选择用CVSNT搭建服务器，用WinCVS作为客户端。CVS服务端配置在任何平台下都需要通过命令来完成，配置过程比较复杂。有时甚至要直接编写配置文件，同时，客户端方面的培植也有些技巧。没有经过培训或者一段时间的研究和测试，无法正常使用CVS完成正常工作和用户、权限的培植管理等工作。
安全和网络
VSS仅可在局域网内部使用，服务器仅作为一个文件服务器，不需要运行任何程序或者起后台服务，但必须要共享一个可写的文件夹。这成为了目前局域网上最容易被病毒入侵的地方，必须定期做好病毒检查工作，安装病毒放火墙。安全性比较差。
CVS在局域网或者广域网内都可使用，作为服务器不需要共享任何资料，但必须起服务，占用系统资源。客户端可以是任何不同平台，都是通过TCP/IP和特定的端口来访问CVS服务器，有不同安全等级的访问协议可供选择。安全性强适用面广。
结论
SourceSafe适合在局域网范围内的，以Windows平台为主的中、小项目，以文件管理为主要功能，使用方便，学习成本低，对服务器仅需要快速大容量的存储器也是它的优势。
CVS可满足局域和广域不同的网络条件，提供不同级别安全性选择，在一台专门服务器的配合下，客户可以使用任何平台开发项目。对于已经完成了开发过程进入项目维护阶段，或者进入项目升级阶段的项目，可提供完善的项目版本管理支持。不过在操作和使用上学习成本比较高。

2、CVS和SVN

有人认为：SVN是CVS的改进版

一、Subversion包含绝大部分CVS功能

Subversion 作为CVS 的重写版和改进版，其目标就是作为一个更好的版本控制软件，取代目前流行的CVS。Subversion 的主要开发人员都是业界知名的CVS 专家。Subversion支持绝大部分的CVS 功能/命令；Subversion 的命令风格和界面也与CVS 非常接近。当然，不同的地方正是对CVS 的改进。

二、全局性的版本编号

一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将Subversion 的版本库看作是一个文件系统或文件目录树的数组。

从技术的角度来说，在Subversion 中，“文件foo.c 的第5 版本”这个说法是错误的；正确的说法应该是：”文件foo.c 在版本库被修改了5 次，即执行5 次commit 后是什么样子？”。显然，在Subversion 中，版本库被修改5 次后foo.c 的内容，和被修改了6 次后foo.c 的内容很可能完全一样，因为版本库的第6 次修改很可能只修改了版本库的其他部分，而并没有对foo.c 的进行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本总是不同的。

Subversion 的全局性版本编号为Subversion 带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，Subversion 不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。

三、目录的版本控制

CVS 只能对文件进行版本控制，不能对目录进行版本控制，因此CVS 没有任何关于文件“移动”（move） 操作的概念。当人为进行文件移动操作时，CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。

同样由于CVS 不记录目录的版本历史，CVS 不支持对文件的“重命名”（rename），人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。

还有，CVS 不支持对文件的“拷贝”（copy），人为的拷贝对CVS 而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。

综上所述，缺乏对文件“移动”、“重命名”、“拷贝”的支持的根源在于CVS 不能记录目录的版本历史，而这些操作在当前的软件开发过程中经常发生，这正是Subversion被开发并取代CVS 的主要原因之一。

Subversion 将目录作为一类特殊的文件来处理（事实上，从文件系统的角度来看，目录确实是一类特殊的文件，当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变）。因此，Subversion 象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion 能够准确记录操作前后的历史联系。同样，象对文件的不同历史版本进行比较一样，Subversion支持对目录的不同历史版本的比较，清晰展现目录的变化历史。

四、原子性提交

从使用者的角度来看，CVS 和Subversion 都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。

CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。

CVS 串行批量提交模式的弊端在于 － 当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。

 

CVS 即使在批量提交不发生中断时也会造成不一致：假设用户A 启动一个需要较长时间才能完成的批量提交；与此同时，用户B 执行cvs update 操作。此时，用户B 很有可能得到一个不一致的更新，即用户B 通过“更新”操作，得到用户A 的部分修改文件。

Subversion 彻底消除了CVS 的以上弊端。无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，Subversion 都会自动执行“回滚”（rollback）操作。换一个说法，Subversion 保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。这就是Subversion 的原子性提交（atomic commit）。

由于Subversion 的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS 的按文件重复存储）。

 

五、支持变更集概念

由于Subversion 的所有提交是原子性的，每次成功提交形成的唯一的全局版本号对应此次批量提交的所有文件修改，也就是说，一个Subversion 版本号其实对应了一个逻辑上的变更集（change set），该变更集可能对应于对一个BUG 的修复，或者对应于对一个已有功能的改进，或者对应于一个新功能的实现。可以说，变更集是一个软件开发活动的逻辑结果，该变更集可以通过其对应的版本号在软件开发的其他过程中（如软件合并/集成过程，软件发布管理，变更管理系统，缺陷追踪系统）被引用。因此，Subversion 将版本管理从单纯的、单个的文件修改的层次通过逻辑上的抽象，上升到更便于理解和交流的开发活动的层次。

 

III、建立Subversion服务

如何快速建立Subversion服务器，并且在项目中使用起来，这是大家最关心的问题，与CVS相比，Subversion有更多的选择，也更加的容易，几个命令就可以建立一套服务器环境，可以使用起来，这里配套有动画教程。
本文是使用Subversion最快速的教程，在最短的时间里帮助您建立起一套可用的服务器环境，只需略加调整就可以应用到实际项目当中。
本教程分为以下几个部门，不仅仅是快速入门，最后我们还有一些高级功能的说明，为了说明简单，教程是在windows下使用的方式，以方便资源有限的项目使用，对于UNIX环境下，区别并不大。

软件下载

服务器和客户端安装

建立版本库（Repository）

配置用户和权限

运行独立服务器

初始化导入

基本客户端操作

1，软件下载

下载Subversion服务器程序。

到官方网站的下载二进制安装文件，来到二进制包下载部分，找到 Windows NT, 2000, XP and 2003部分，然后选择" this directory "，这样我们可以看到许多下载的内容，目前可以下载 svn-1.4.0-setup.exe 。

下载Subversion的Windows客户端TortoiseSVN。

TortoiseSVN是扩展Windows Shell的一套工具，可以看作Windows资源管理器的插件，安装之后Windows就可以识别Subversion的工作目录。
官方网站是TortoiseSVN ，下载方式和前面的svn服务器类似，在Download页面的我们可以选择下载的版本，目前的最高稳定版本的安装文件为TortoiseSVN-1.4.0.7501-win32-svn-1.4.0.msi。

2，服务器和客户端安装

服务器安装，直接运行svn-1.4.0-setup.exe ，根据提示安装即可，这样我们就有了一套服务器可以运行的环境。

安装TortoiseSVN，同样直接运行TortoiseSVN-1.4.0.7501-win32-svn-1.4.0.msi按照提示安装即可，不过最后完成后会提示是否重启，其实重启只是使svn工作拷贝在windows中的特殊样式生效，与所有的实际功能无关，这里为了立刻看到好的效果，还是重新启动机器。
 

3，建立版本库（Repository）

运行Subversion服务器需要首先要建立一个版本库（Repository），可以看作服务器上存放数据的数据库，在安装了Subversion服务器之后，可以直接运行，如：

svnadmin create E:/svndemo/repository

就会在目录E:/svndemo/repository下创建一个版本库。

我们也可以使用TortoiseSVN图形化的完成这一步：
在目录E:/svndemo/repository下"右键->TortoiseSVN->Create Repository here...“， 然后可以选择版本库模式， 这里使用默认即可， 然后就创建了一系列目录和文件。

4，配置用户和权限

来到E:/svndemo/repository/conf目录，修改svnserve.conf：
# [general]
# password-db = passwd
改为：
[general]
password-db = passwd 然后修改同目录的passwd文件，去掉下面三行的注释：
# [users]
# harry = harryssecret
# sally = sallyssecret
最后变成：
[users]
harry = harryssecret
sally = sallyssecret

 

5，运行独立服务器

在任意目录下运行：
svnserve -d -r E:/svndemo/repository 我们的服务器程序就已经启动了。注意不要关闭命令行窗口，关闭窗口也会把svnserve停止。

（显然这样是不好的，所以要把他注册成为windows服务程序，开机自动在后台运行。详细见IV）
6，初始化导入

来到我们想要导入的项目根目录，在这个例子里是E:/svndemo/initproject，目录下有一个readme.txt文件：

右键->TortoiseSVN->Import...
URL of repository输入“svn://localhost/”
ok
完成之后目录没有任何变化，如果没有报错，数据就已经全部导入到了我们刚才定义的版本库中。

需要注意的是，这一步操作可以完全在另一台安装了TortoiseSVN的主机上进行。例如运行svnserve的主机的IP是133.96.121.22，则URL部分输入的内容就是“svn://133.96.121.22/”。

7，基本客户端操作

取出版本库到一个工作拷贝：
来到任意空目录下，在本例中是E:/svndemo/wc1，运行右键->Checkout，在URL of repository中输入svn://localhost/，这样我们就得到了一份工作拷贝。
在工作拷贝中作出修改并提交：
打开readme.txt，作出修改，然后右键->Commit...，这样我们就把修改提交到了版本库，我们可以运行。

察看所作的修改：
readme.txt上右键->TortoiseSVN->Show Log，这样我们就可以看到我们对这个文件所有的提交。在版本1上右键->Compare with working copy，我们可以比较工作拷贝的文件和版本1的区别。

 

IV、注册服务

下载SVNService，Google吧！

SVN Service Wrapper for Windows
This is my Win32 Service wrapper for SVN. Source is included, and its in the public domain. No need to copyright this stuff.

Usage instructions:

  SVNService -?                               to display this list
  SVNService -install <svnserve parameters>   to install the service
  SVNService -setup <svnserve parameters>     to change command line parameters for svnserve
  SVNService -remove                          to remove the service
  SVNService -debug                           to run as a console app for debugging

将svnservice.exe放在subversion的bin目录下

Example:
比如，你的所有项目都在c:/svnrepo下，你可以如下
安装时用  SVNService -install -d -r c:/svnrepo
更改时用  SVNService -setup -d -r c:/otherplace/svnrepo
如果访问其中的一个项目c:/svnrepo/project1，可以指定路径

svn://localhost/project1 (注：作为url时用/)

第一次安装完后要到服务中手动启动它，
或者到服务中将它设为自动启动，让每次机器启动时自动启动这个服务。

IMPORTANT:

  Make sure you place SVNService.exe in the same directory as svnserve.exe
  一定要将SVNService.exe放在svnserve.exe相同的目录
Special thanks go to Craig Link at Microsoft for creating the initial service.c.

-Magnus Norddahl

 

V、权限详解

对于工作日志，原先采用邮件方式发给经理，但是这种方式有个缺点，那就是不具备连续性，要看以前的日志必须一封一封邮件去查看，很麻烦。于是就想到利用 Subversion， 让员工在自己电脑上编辑日志，然后利用svn传送回来，既方便员工自己编写日志，又方便对日志的归档处理，而且提交日志的时候只需要执行一下 svn update 即可，比发送邮件还要简单的多。

svn服务器相关信息

服务器地址： 192.168.0.1

服务器OS： MS Windows 2000 Server Edition 中文版

代码库本地目录： D:/svn/arm

arm部门文档的目录结构如下:

arm                 部门名称

├─diary           工作日志目录

│  ├─headquarters    总部工作日志目录

│  ├─beijing         北京办日志目录

│  └─shanghai        上海办日志目录

├─ref             公司公共文件参考目录

└─temp            临时文件目录

人员情况

morson，公司总经理，其实他不必亲自看任何东西，就连部门经理们的每周总结都不一定看。但是为了表示对他的尊敬，以及满足一下他的权力欲，还是给他开放了“阅读所有文档”的权限

michael，arm事业部的部门经理，没事的时候喜欢弄点儿新技术，用svn来管理日志，就是他相处来的主意

scofield，北京办人员，老员工，为人油滑难管

lincon，上海办人员，老员工，大老实人一个

linda，总部协调员、秘书，文笔不错，长得也不错

rory，单片机技术员，技术支持

访问权限需求分析

允许总经理读取所有文件

除部门经理外，所有其他人员，均只能看到本办事处人员工作日志

不允许匿名访问

ref目录只允许经理和秘书写，对其他人只读

temp目录人人都可以写

2   建立代码库

在服务器 D:/svn 目录下，建立 arm 代码库，命令如下:

D:/svn>svnadmin create arm

在客户机 F:/temp 目录下，建立好上述目录结构

用命令 F:/temp>svnimportarmsvn://192.168.0.1/arm 导入结构

【注意点：关于导入时候的细微差别】

3   编辑代码库基础配置文件

编辑代码库 arm/conf/svnserve.conf 文件，如下:

[general]

password-db = passwd.conf

anon-access = none

auth-access = write

authz-db = authz.conf

4   管理用户帐号

新建代码库 arm/conf/passwd.conf 文件，如下:

[users]

morson = ShowMeTheMoney

michael = mysecretpassword

scofield = hellolittilekiller

lincon = asyouknows111

rory = 8809117

linda = IlikeWorldCup2006

5   建立目录访问权限控制文件

新建代码库 arm/conf/authz.conf 文件，内容如下:

[groups]

g_vip = morson

g_manager = michael

g_beijing = scofield

g_shanghai = lincon

g_headquarters = rory, linda

g_docs = linda

[arm:/]

@g_manager = rw

* = r

[arm:/diary/headquarters]

@g_manager = rw

@g_headquarters = rw

@g_vip = r

* =

[arm:/diary/ beijing ]

@g_manager = rw

@g_beijing = rw

@g_vip = r

* =

[arm:/diary/shanghai]

@g_manager = rw

@g_shanghai = rw

@g_vip = r

* =

[arm:/ref]

@g_manager = rw

@g_docs = rw

* = r

[arm:/temp]

* = rw

6   测试

在服务器上，打开一个 DOS Prompt 窗口，输入如下指令:

svn co svn://127.0.0.1/arm --no-auth-cache --username rory --password 8809117

我们应该得到如下目录结构:

arm

├─diary

│  └─headquarters

├─ref

└─temp

然后修改ref目录下任意文件并提交，服务器将会报错“Access deni”

深入

本章将详细介绍前一章所涉及的两个配置文件， svnserve.conf 和 authz.conf，通过对配置逐行的描述，来阐明其中的一些细节含义。

这里首先要注意一点，任何配置文件的有效配置行，都不允许存在前置空格，否则程序会无法识别。也就是说，如果你直接从本文的纯文本格式中拷贝了相关的配置行过去，需要手动将前置的4个空格全部删除。当然了，如果你觉得一下子要删除好多行的同样数目的前置空格是一件苦差使，那么也许 UltraEdit 的“Column Mode”编辑模式，可以给你很大帮助呢。

1   svnserve.conf

arm/conf/svnserve.conf 文件，是 svnserve.exe 这个服务器进程的配置文件，我们逐行解释如下。

首先，我们告诉 svnserve.exe，用户名与密码放在 passwd.conf 文件下。当然，你可以改成任意的有效文件名，比如默认的就是 passwd:

password-db = passwd.conf

接下来这两行的意思，是说只允许经过验证的用户，方可访问代码库。 那么哪些是“经过验证的”用户呢？噢，当然，就是前面说那些在 passwd.conf 文件里面持有用户名密码的家伙。这两行的等号后面，目前只允许 read write none 三种值，你如果想实现一些特殊的值，比如说“read-once”之类的，建议你自己动手改源代码，反正它也是自由软件:

anon-access = none

auth-access = write

接下来就是最关键的一句呢，它告诉 svnserve.exe，项目目录访问权限的相关配置是放在 authz.conf 文件里:

authz-db = authz.conf

当然，svn 1.3.2 引入本功能的时候，系统默认使用 authz 而不是 authz.conf 作为配置文件。不过由于鄙人是处女座的，有着强烈的完美主义情结，看着 svnserve.conf 有后缀而 passwd 和 authz 没有就是不爽，硬是要改了。

2   authz.conf 之用户分组

arm/conf/authz.conf 文件的配置段，可以分为两类，``[group]`` 是一类，里面放置着所有用户分组信息。其余以 [arm:/] 开头的是另外一类，每一段就是对应着项目的一个目录，其目录相关权限，就在此段内设置。

首先，我们将人员分组管理，以便以后由于人员变动而需要重新设置权限时候，尽量少改动东西。我们一共设置了5个用户分组，分组名称统一采用 g_ 前缀，以方便识别。当然了，分组成员之间采用逗号隔开:

[groups]

# 任何想要查看所有文档的非本部门人士

g_vip = morson

# 经理

g_manager = michael

# 北京办人员

g_beijing = scofield

# 上海办人员

g_shanghai = lincon

# 总部一般员工

g_headquarters = rory, linda

# 小秘，撰写文档

g_docs = linda

注意到没有， linda 这个帐号同时存在“总部”和“文档员”两个分组里面，这可不是我老眼昏花写错了，是因为 svnserve.exe 允许我这样设置。它意味着，这个家伙所拥有的权限，将会比他的同事 rory 要多一些，这样的确很方便。具体多了哪些呢？请往下看！

3   authz.conf 之项目根目录

接着，我们对项目根目录做了限制，该目录只允许arm事业部的经理才能修改，其他人都只能眼巴巴的看着:

[arm:/]

@g_manager = rw

* = r

[arm:/] 表示这个目录结构的相对根节点，或者说是 arm 项目的根目录

这里的 @ 表示接下来的是一个组名，不是用户名。你当然也可以将 @g_manager=rw 这一行替换成 michael=rw ，而表达的意义完全一样。

* 表示“除了上面提到的那些人之外的其余所有人”，也就是“除了部门经理外的其他所有人”，当然也包括总经理那个怪老头

* = r 则表示“那些人只能读，不能写”

4   authz.conf 之项目子目录

然后，我们要给总部人员开放日志目录的读写权限:

[arm:/diary/headquarters]

@g_manager = rw

@g_headquarters = rw

@g_vip = r

* =

我敢打赌，设计svn的家伙们，大部分都是在 unix/linux 平台下工作，所以他们总喜欢使用 / 来标识子目录，而完全忽视在 MS Windows 下是用 / 来做同样的事情。所以这儿，为了表示 arm/diary/headquarters 这个目录，我们必须使用 [arm:/diary/headquarters] 这样的格式。

这里最后一行的 *= 表示，除了经理、总部人员、特别人士之外，任何人都被禁止访问本目录。这一行是否可以省略呢？

之所以这儿需要将 @g_vip=r 一句加上，就是因为存在上述这个解释。如果说你没有明确地给总经理授予读的权力，则他会和其他人一样，被 * 给排除在外。

如果众位看官中间，有谁玩过防火墙配置的话，可能会感觉上述的配置很熟悉。不过这里有一点与防火墙配置不一样，那就是各个配置行之间，没有 先后顺序 一说。也就是说，如果我将本段配置的 *= 这一行挪到最前面，完全不影响整个配置的最终效果。

请注意这儿，我们并没有给 arm/diary 目录设置权限，就直接跳到其子目录下进行设置了。我当然是故意这样的，因为我想在这儿引入“继承”的概念。

权限具备继承性 任何子目录，均可继承其父目录的所有权限，除非它自己被明确设置了其他的权限。也就是说，在 arm 目录设置权限后， arm/diary 目录没有进行设置，就意味着它的权限与 arm 目录一样，都是只有经理才有权读写，其他人只能干瞪眼。

【 * = 是否可以省略】【用例子引入覆盖】【单用户权限的继承问题】【父目录权限集成与全面覆盖问题】

现在来看看

好了，我们现在掌握了“继承”的威力，它让我们节省了不少敲键盘的时间。可是现在又有一个问题了，

属性具备覆盖性质子目录若设置了属性，则完全覆盖父目录。

5   authz.conf 的其他注意点

父目录的 r 权限，对子目录 w 权限的影响

把这个问题专门提出来，是因为在 1.3.1 及其以前的版本里面，有个bug，即为了子目录的写权限，项目首目录必须具备读权限。因此现在使用了1.3.2版本，就方便了那些想在一个代码库存放多个相互独立的项目的管理员，来分配权限了。比如说央舜公司建立一个大的代码库用于存放所有员工日志，叫做 diary，而arm事业部只是其中一个部门，则可以这样做:

[diary:/]

@g_chief_manager = rw

[diary:/arm]

@g_arm_manager = rw

@g_arm = r

这样，对于所有arm事业部的人员来说，就可以将 svn://192.168.0.1/diary/arm 这个URL当作根目录来进行日常操作，而完全不管它其实只是一个子目录，并且当有少数好奇心比较强的人想试着 checkout 一下 svn://192.168.0.1/diary 的时候，马上就会得到一个警告“Access deni”，哇，太酷了。

默认权限

如果说我对某个目录不设置任何权限，会怎样？马上动手做个试验，将:

[diary:/]

@g_chief_manager = rw

改成:

[diary:/]

# @g_chief_manager = rw

这样就相当于什么都没有设置。在我的 svn 1.3.2 版本上，此时是禁止任何访问。也就是说，如果你想要让某人访问某目录，你一定要显式指明这一点。这个策略，看起来与防火墙的策略是一致的。

只读权限带来的一个小副作用

若设置了:

[arm:/diary]

* = r

则svnserve认为，任何人，都不允许改动diary目录，包括删除和改名，和新增。

也就是说，如果你在项目初期创建目录时候，一不小心写错目录名称，比如因拼写错误写成 dairy，以后除非你改动 authz.conf 里面的这行设置，否则无法利用 svn mv 命令将错误的目录更正。

改进

1   对中文目录的支持

上午上班的时候，Morson 来到 Michael 的桌子前面，说道：“你是否可以将我们的北京办、上海办目录，改成用中文的，看着那些拼音我觉得很难受？” Michael 心想，还好这两天刚了解了一些与 unicode 编码相关的知识，于是微笑地回答：“当然可以，你明天下午就可以看到中文目录名称了。”

使用 svn mv 指令，将原来的一些目录改名并 commit 入代码库，改名后的目录结构如下:

arm

├─工作日志

│  ├─总部人员

│  ├─北京办

│  └─上海办

├─公司公共文件参考目录

└─临时文件存放处

修改代码库的 authz.conf 文件，将相应目录逐一改名

使用 UltraEdit 将 authz.conf 文件转换成不带 BOM 的 UTF-8 格式

将配置文件转换成 UTF-8 格式之后，Subversion 就能够正确识别中文字符了。但是这里需要注意一点，即必须保证 UTF-8 文件不包含 BOM 。BOM 是 Byte Order Mark 的缩写，指 UNICODE 文件头部用于指明高低字节排列顺序的几个字符，通常是 FFFE ，而将之用 UTF-8 编码之后，就是 EFBBBF 。由于 UTF-8 文件本身不存在字节序问题，所以对 UTF-16 等编码方式有重大意义的 BOM，对于 UTF-8 来说，只有一个作用——表明这个文件是 UTF-8 格式。由于 BOM 会给文本处理带来很多难题，所以现在很多软件都要求使用不带 BOM 的 UTF-8 文件，特别是一些处理文本的软件，如 PHP、 UNIX 脚本文件等，svn 也是如此。

目前常用的一些文本编辑工具中，MS Windows 自带的“记事本”里面，“另存为”菜单保存出来的 UTF-8 格式文件，会自动带上 BOM 。新版本 UltraEdit 提供了选项，允许用户选择是否需要 BOM，而老版本的不会添加 BOM。请各位查看一下自己常用的编辑器的说明文件，看看它是否支持这个功能。

利用 UltraEdit ，我们可以将 BOM 去掉。方法是，首先利用“UTF-8 TO ASCII”菜单将文件转换成本地编码，通常是GB 2312 码 ，然后再使用“ASCII TO UTF-8(UNICODE Editing)”来转换到 UTF-8 即可。

 

VI、SVN迁移

（CVS库向SVN的迁移可以参看最后的链接）

SVN迁移可能有很多原因, 可能是我们想换Repository目录, 或者是想换一台机器, 等等.
SVN迁移很容易做, 按照下面步骤就可以:

1. 将原来的Repository导出为一个文件dumpfile
> svnadmin dump path/to/old-repo > dumpfile

2. 创建新的Repository, 创建方法可以参考 Windows 平台安装Subversion server
3. 将dumpfile导入到新的Repository
> svnadmin load path/to/new-repo < dumpfile

4. 检查新的Repository的conf/目录下的配置文件, 检查hooks/目录下的构子程序等等...

本机SVN的快速迁移方法:(感谢R2的提示)
svnadmin hotcopy old_rep_path new_rep_path

 

VII、其他资料

HTTP://WWW.CNBLOGS.COM/JAVA_AIX/ARCHIVE/2005/02/08/103399.HTML

HTTP://WWW.CNBLOGS.COM/JAVA_AIX/ARCHIVE/2005/02/10/103717.HTML

http://www.cnblogs.com/iaxes/articles/43184.html

http://www.blogjava.net/yongbing/archive/2007/03/04/101761.html

http://doc.iusesvn.com/show-29-1.html