centos上安装使用和升级subversion&Apache

关于安装和使用

 

可以参见http://wiki.centos.org/HowTos/Subversion

Subversion on CentOS

Subversion isn't just for coders and programmers...I know because I'm not one. I've begun to use it lately for many things, such as, backing up Nagios configurations, documents, and pretty much anything text based. I don't know why I didn't start using it sooner, but none the less, here I am. This document quickly explains how to install, configure, and use subversion locally, as well as across Apache on a network. For complete and complex configurations and installations seek the documentation provided. There is plenty of well written documentation on the subject, that far exceeds my knowlegde of the tool. This just helps get you started quickly, for those like me that just like to jump in head first into new things.

 

Contents

1. System
2. References
3. Installation
4. Configurations
5. Using Subversion
6. Access control lists
7. Afterthought
8. Further reading

 

1. System

CentOS 4.x/RHEL 4
CentOS 5.1/RHEL 5

 

2. References

Subversion: http://subversion.tigris.org/ 
Version Control with Subversion: http://svnbook.red-bean.com/ 

 

3. Installation

 

[root@lucifer ~]# yum install mod_dav_svn subversion

The first thing to do is to install the packages I mentioned above. If you don't have Apache installed already, it'll go ahead and drag that down as well.

When you install from yum, there's a longer list than the two packages above that will automatically resolve themselves. Some other things will be installed automatically. Depending on your packages, your mileage may vary.

 

4. Configurations

 

4.1. Apache

Before you delve into the deep end, you need to ensure Apache is set up first. I'm assuming this is a virgin installation, so if you already have Apache things going...be careful what you change. I'm also going to explain setting this up with basic password protection. You can easily let this out, however, if you want to allow access to the repos from everyone.

First thing is make sure you open up /etc/httpd/conf/httpd.conf and at least change the ServerName directive. If you need more help or more complex configurations, then consult the Apache docs please.

 

[root@lucifer ~] vim /etc/httpd/conf/httpd.conf -- Edit what you need and save the file[root@lucifer ~] service httpd start[root@lucifer ~] chkconfig httpd on

Browse to your machine on the network and see if you get your test page, which you should: http://yourmachine. Working? Great, let's move along to more fun things.

 

4.2. Subversion's Apache configs

The next step is to setup some settings within Apache so Subversion and Apache play nice together. Get yourself to the example configuration file Subversion installed for you.

 

[root@lucifer ~] cd /etc/httpd/conf.d/[root@lucifer ~] vim subversion.conf# Make sure you uncomment the following if they are commented outLoadModule dav_svn_module     modules/mod_dav_svn.soLoadModule authz_svn_module   modules/mod_authz_svn.so# Add the following to allow a basic authentication and point Apache to where the actual# repository resides.<Location /repos>        DAV svn        SVNPath /var/www/svn/repos        AuthType Basic        AuthName "Subversion repos"        AuthUserFile /etc/svn-auth-conf        Require valid-user</Location>

The location is what Apache will pass in the URL bar. For instance: http://yourmachine/repos points to the SVNPath that you have specified. My examples are just that, so feel free to put things where you want. Make sure you save the file when you are finished editing.

Next we have to actually create the password file that you specified in the previous step. Initially you'll use the -cm arguments. This creates the file and also encrypts the password with MD5. If you need to add users make sure you simply use the -m flag, and not the -c after the initial creation.

 

[root@lucifer ~] htpasswd -cm /etc/svn-auth-conf yourusernameNew password:Re-type new password:Adding password for user yourusername[root@lucifer ~] htpasswd -m /etc/svn-auth-conf anotherusernameNew password:Re-type new password:Adding password for user anotherusername

 

4.3. Configure your repository

The next thing you need to do is to create the actual repository from which you will check in and out your files. This is simple to do with some of the included svn tools.

 

[root@lucifer ~] cd /var/www/ -- Or wherever you placed your path above[root@lucifer ~] mkdir svn[root@lucifer ~] cd svn[root@lucifer ~] svnadmin create repos[root@lucifer ~] chown -R apache.apache repos[root@lucifer ~] service httpd restart

Go test out whether or not you can access your repository from a web browser: http://yourmachine/repos. You should get a popup box asking for a username and password. If so, type in your credentials and you should be displayed with a Revision 0:/ page. If so, that's it for setting up a repo. If you want multiple repos, check out the docs from the links provides above. This sets up one repository and shows you how to start using them. Speaking of, let's move on to just that.

 

5. Using Subversion

 

5.1. Layout Your Repo

If all went well above, you're now ready to start using the repository that you created. Subversions svn tool is the command line client that you will use to talk to the database. To see the use of the tool:

 

[root@lucifer ~] svn --help

The most common arguments you will most likely be using are: svn import, svn commit (ci), and svn checkout (co). With these you will initially import files into your repository with import, you'll check them out to work on them with checkout, and you'll commit the changes back into the database with commit. It's pretty simple once you see them in use a few times.

Before I continue I'd like to explain about directory structure layouts. Almost all of the documentation talks about creating a certain layout for your directories. They specifically mention about making sure you have a branches, tags, and trunk underneath the root directory structure, where trunk holds all your files. For instance:

 

.|-- project1|   |-- branches|   |-- tags|   `-- trunk`-- project2    |-- branches    |-- tags    `-- trunk

The book explains why in a bit more detail, and I mainly don't bother using this type of layout...because I'm not doing coding and maintaining "projects" per se. I'm mainly using it to store configuration files, and text items that aren't as complex. Set things up for whatever works for you.

As an example, I'm going to just create some dummy directories and throw some files in them. This is from the actual SVN server. Play along.

 

[root@lucifer ~] cd /tmp[root@lucifer ~] mkdir mytestproj[root@lucifer ~] cd mytestproj[root@lucifer ~] mkdir configurations options main[root@lucifer ~] vim configurations/testconf1.cfg -- Add whatever you want to these files.[root@lucifer ~] vim options/testopts1.cfg[root@lucifer ~] vim main/mainfile1.cfg

Keep in mind that you can layout anything anyway you'd like. Once you have the initial layout of what you want, let's go ahead and import this up to Subversion.

 

5.2. Importing

 

[root@lucifer ~] svn import /tmp/mytestproj/ file:///var/www/svn/repos/mytestproj -m "Initial repository layout for mytestproj"Adding         /tmp/mytestproj/mainAdding         /tmp/mytestproj/main/mainfile1.cfgAdding         /tmp/mytestproj/configurationsAdding         /tmp/mytestproj/configurations/testconf1.cfgAdding         /tmp/mytestproj/optionsAdding         /tmp/mytestproj/options/testopts1.cfg

 

5.3. Checking Out

Now, just to check it out across the web browser: http://yourmachine/repos. You'll get whatever you have imported showing up to peruse. Once you upload your original layout from the local SVN server, you're now free to use it remotely on another machine. As long as you are connecting to the Subversion server with the user account(s) that you created earlier. Let's give it a shot.

 

[me@mylappy ~] cd /tmp[me@mylappy ~] svn co http://yoursvnserver/repos/mytestprojAuthentication realm: <http://yoursvnserver:80> Subversion reposPassword for 'youruser':A    mytestproj/mainA    mytestproj/main/mainfile1.cfgA    mytestproj/configurationsA    mytestproj/configurations/testconf1.cfgA    mytestproj/optionsA    mytestproj/options/testopts1.cfgChecked out revision 1.

 

5.4. Edit & Commit

As you can see, you've checked out revision 1 from the Subversion server. Now you can edit some things and commit the changes back to the Subversion server.

 

[me@mylappy ~] cd mytestproj[me@mylappy ~] vim configurations/testconf1.cfg -- Add or delete something and save.[me@mylappy ~] svn commit -m "Added a line to testconf1.cfg."Sending        configurations/testconf1.cfgTransmitting file data .Committed revision 2.

The nice thing about this then, is that you can delete all of the directories that you just checked out on your machine. The only reason you checked them out, was to edit them, and then send them back up the line. Web browse to your server to check out the different files.

 

5.5. Adding/Deleting Items

Now this is all fine and dandy, but how do you add more files to an already existing repo directory? Easy, with the add argument. Go ahead and checkout your latest and greatest, copy a file over to a directory, add, then commit the changes.

 

[me@mylappy ~] svn co http://yoursvnserver/repos/mytestprojA    mytestproj/mainA    mytestproj/main/mainfile1.cfgA    mytestproj/configurationsA    mytestproj/configurations/testconf1.cfgA    mytestproj/optionsA    mytestproj/options/testopts1.cfgChecked out revision 2.[me@mylappy ~] cd mytestproj[me@mylappy ~] cp /etc/yum.repos.d/CentOS-Base.repo configurations/[me@mylappy ~] svn add configurations/CentOS-Base.repoA         configurations/CentOS-Base.repo[me@mylappy ~] svn commit -m "Added the CentOS Yum repo file."Adding         configurations/CentOS-Base.repoTransmitting file data .Committed revision 3.

To delete items simply use delete instead of add. Commit your changes back up, and you're good to go. It's as simple as that. Go back over to your web browser again and you'll notice the revision number should say 3. You'll be able to click through the files to pick our your differences as well.

 

5.6. Reverting Back

Ok, this is all great but how do I revert back to an older revision...isn't this the point of Subversion? Yep, it's easy. If you're not sure as to what revision you're at...check out the log command. This is why you put a message in every commit. Short and to the point, but enough information to ring a bell that you perhaps forgot about.

 

[me@mylappy ~] svn log http://yoursvnserver/repos -- For the entire repository[me@mylappy ~] svn log http://yoursvnserver/repos/mytestproj -- For the specific project

You'll get a nice complete list of revision numbers along with the comments, like I mentioned above. This allows you to pick which revision you want to check back out now.

 

[me@mylappy ~] svn co -r 1 http://yoursvnserver/repos/mytestproj

This command will drag down revision number 1.

 

6. Access control lists

Usually, you don't want to give every user access to every repository. You can restrict repository access per user by using ACLs. ACLs can be enabled with the AuthzSVNAccessFile file option, which takes a file name as its parameter. For instance:

 

AuthzSVNAccessFile /etc/svn-acl-conf

You can add this to the relevant Location section:

 

<Location /repos>        DAV svn        SVNParentPath /var/www/svn/repos        AuthzSVNAccessFile /etc/svn-acl-conf        AuthType Basic        AuthName "Subversion repos"        AuthUserFile /etc/svn-auth-conf        Require valid-user</Location>

You can then create /etc/svn-acl-conf. This file consist of sections of the following form:

 

[reponame:repopath]user = access

Where access can be r (read), rw (read-write), or empty (no access at all). The default ACL is to give users no access to a repository. Suppose that there is a repository named framework to which you would like to give john read access, and joe read and write access. You could then add the following section:

 

[framework:/]john =  rjoe = rw

It is also possible to create groups in a section named groups, groups are then prefixed with the 'at' sign (@) in the access control lists. For instance:

 

[groups]staff = joe, george[framework:/]john =  r@staff = rw

If you would like to make all repositories readable to all users, you can add a section for the root directory of every repository:

 

[/]* = r

 

7. Afterthought

This is only a very very small part of the power of what Subversion can offer you. This quick guide will get you going, and show you how to use it a bit to understand how it's working. You can do all kinds of things with the Subversion tools, so make sure you check the docs out to learn about different options that might assist you in your tasks. Also remember that the Apache installation might be overkill for your needs. You can completely use the Subversion tools locally on a machine by specifying file:///path/to/repo, instead of my examples across Apache as http://yoursvnserver/repos/whatever. From what I read, many folks use it on their local boxes just to keep their minds straight for huge projects and configurations file. Good luck

 

8. Further reading

• Version Control with Subversion

   

   

但使用yum install subversion安装的版本是1.4的， 要升级的话，参见

http://www.freshblurbs.com/upgrading-subversion-1-5-centos-5-2-using-yum

Upgrading Subversion to 1.5 on CentOS 5.2 Using Yum

Default CentOS 5.2 yum repositories are still on Sybversion 1.4.x branch, so if you need the latest Subversion client, you are out of luck... or not, if you read this blog post :) This quick tutorial will show you how to upgrade in less than 5 minutes.

We will use RPMForge repos for the upgrade.

• Download and install proper RPMForge repo RPM for your server architecture (64bit or 32bit) from RPMForge website.
• Edit /etc/yum.repos.d/rpmforge.repo and change enabled=1 to "0". We do not want this repo to be enabled by default, because an accidental "svn update" will update all your packages to bleeding-edge, test-quality versions. RPMForge has many experimental rpms.
• Run: yum --enablerepo=rpmforge check-update subversion and make sure the version of subversion you are looking for is available. It should show you something like:
  

  rpmforge 100% |=========================| 1.1 kB  00:00     subversion.x86_64    1.5.5-0.1.el5.rf  rpmforge       

• Check for existing subversion clients:

   

  # rpm -qa | grep -i subversionsubversion-1.4.2-2.el5subversion-1.4.2-2.el5

• Apparently there're two rpms installed (happens sometimes) so we need to add special flag to rpm -evf to safely remove it:

   

  rpm -evf --allmatches subversion-1.4.2-2.el5

• Obviously, in your case there may not be previous installation or the version may be different.

   

• Run install:
  

  yum --enablerepo=rpmforge --disablerepo=base install subversion

  Please note that we are enabling rpmforge repo and disabling "base" repo that has 1.4.x version of Subversion, since yum would try to install it, as well. If yum finds other repos with 1.4.x, you may need to disable them as well.

  cheers

还有http://stackoverflow.com/questions/96597/how-do-i-upgrade-to-subversion-1-5-on-centos-5

 

另外，有些关于subversion的资料：

http://coldtear.javaeye.com/blog/28440

【转贴】Subversion权限详解

1   背景假设

厦门央瞬公司是一家电子元器件设备供应商，其中有个ARM部门，专门负责ARM芯片的方案设计、销售，并在北京、上海各设立了一个办事处。对于工作日志，原先采用邮件方式发给经理，但是这种方式有个缺点，那就是不具备连续性，要看以前的日志必须一封一封邮件去查看，很麻烦。于是就想到利用 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.confanon-access = noneauth-access = writeauthz-db = authz.conf

4   管理用户帐号

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

[users]morson = ShowMeTheMoneymichael = mysecretpasswordscofield = hellolittilekillerlincon = asyouknows111rory = 8809117linda = IlikeWorldCup2006

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

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

[groups]g_vip = morsong_manager = michaelg_beijing = scofieldg_shanghai = lincong_headquarters = rory, lindag_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 = noneauth-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 的其他注意点

1. 父目录的 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”，哇，太酷了。

1. 默认权限

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

[diary:/]@g_chief_manager = rw

改成:

[diary:/]# @g_chief_manager = rw

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

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

若设置了:

[arm:/diary]* = r

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

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

改进

1   对中文目录的支持

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

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

   arm├─工作日志│  ├─总部人员│  ├─北京办│  └─上海办├─公司公共文件参考目录└─临时文件存放处

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

3. 使用 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 也是如此。

    

   还有ibm文档

   可以去http://www.ibm.com/developerworks/cn/opensource/搜索subversion

   下面是其中一篇文章

   http://www.ibm.com/developerworks/cn/java/j-lo-apache-subversion/

   用 Apache 和 Subversion 搭建安全的版本控制环境

   文档选项

   打印本页

   

   将此页作为电子邮件发送

   
   

   级别： 中级

   吴 玥颢 ([e-mail]), 软件工程师, IBM
   胡 睿 ([e-mail]), 软件工程师, IBM

   2006 年 9 月 11 日

   作为新一代的开源版本控制工具，Subversion 以其目录版本化、原子提交、版本化的元数据、更加有效的分支和标签等优良特性，正逐渐受到开源软件社区的重视，并有望取代 CVS，成为开源软件开发中版本控制的首选系统。在服务器端，Subversion 最大的独特之处，在于它可以通过一个扩展模块与 Apache 的 HTTP 服务器相结合，实现很多高级的管理功能和安全特性。与 CVS 相比，Subversion 实现了更加先进和安全的用户认证功能。在 Apache 的支持下，用户可以通过 HTTP 协议访问版本库，管理员可以对用户访问 HTTP 的权限做出具体的设置，同时 Subversion 还可以获得 SSL 传输加密，用户数据加密，以及目录级的访问控制等特性。

   本文将在服务器端配置工作的角度，结合作者在实际开发工作当中的配置实例，介绍 Subversion 服务器端的基本配置和管理，以及如何将 Subversion 与 Apache 结合，实现一些高级管理功能。

   Subversion 简介

   在开源软件的开发过程当中，由于开发方式自由和开发人员分散这些特性，版本控制问题一直是关系到项目成败的重要问题。没有版本控制系统的支持，开源软件的开发过程就是混乱和不可控制的。

   长期以来，CVS 作为一种普遍采用的开源版本控制工具，在很多的开源软件项目当中充当了重要的角色。在 Eclipse 当中，更是把 CVS 作为一个默认的插件，与 Ant，JUnit 等工具并列在一起，成为 Eclipse 软件开发的基本工具。近年来，随着开源社区的发展，一种功能更加强大的开源版本控制工具逐渐进入了人们的视野，那就是 Subversion，凭借着更为优秀的特性，Subversion 正在逐步取代 CVS，成为新一代的开源版本控制工具。

   相比 CVS，Subversion 中的目录、文件以及改名等元数据都是被版本化的，例如文件的改名、拷贝等等操作；而且，在 Subversion 中，提交操作是不可分割的，修订版本号是基于每次提交操作而非文件；另外，Subversion 可以独立运行，有着轻量级的分支（Branching）与标签（Tagging）操作，版本库可以采用数据库（Berkeley DB）或者是使用特定格式的文件进行存储，对二进制文件进行处理更为有效；最后，Subversion 工具以及相关插件都有着很好的国际化支持，可以支持包括简体中文在内的多种语言版本，方便全球各地的开发人员。这些优秀的新特性，使得 Subversion 成为开源社区目前的最佳选择。

   对于普通用户，即应用程序开发者而言，尤其是对 Eclipse 的用户而言，Subversion 的使用十分的简单。通过官方提供的 Eclipse 插件 Subclipse，用户可以在 Eclipse 里面很方便的使用 Subversion 客户端的各项基本功能。具体的客户端设置和使用方法，请参考 Subversion 官方网站和 Subclipse 官方网站。简单说来，在 Eclipse 中使用 Subversion 插件的基本功能，如更新、提交、同步、分支等等，基本上同使用 Eclipse 自带的 CVS 插件一模一样，这样，用户就可以从 CVS 方便的转移到 Subversion。

   目前，Subversion 已经升级到 1.3.2 版本，相关下载、特性说明和详细使用手册可以在 Subversion 主页上找到。

   简单的版本库管理

   有了简单易用的客户端，大部分的用户都可以轻松使用 Subversion 了，不过，作为服务器端的管理人员，还必须进一步了解服务器端的基本配置管理，才可以充分利用 Subversion 的各项优秀特性。

   版本库创建

   Subversion 的版本库（repository），就是位于服务器端，统一管理和储存数据的地方。本文中，我们以 Linux 为例，介绍在服务器端配置和管理 Subversion 版本库的基本方法。

   要创建一个版本库，首先要确定采用哪种数据存储方式。在 Subversion 中，版本库的数据存储有两种方式，一种是在 Berkeley DB 数据库中存放数据；另一种是使用普通文件，采用自定义的格式来储存，称为 FSFS。

   两种存放方式各有优缺点，读者可以参考 http://svnbook.org/ 上面的文档来了解两者详细的比较和区别，这里，我们仅引用上述文档当中的简单对照表，给出一个简明的比较。

   
   表1 两种版本库数据存储对照表
   特性Berkeley DBFSFS对操作中断的敏感很敏感；系统崩溃或者权限问题会导致数据库“塞住”，需要定期进行恢复。不敏感可只读加载不能可以存储平台无关不能可以可从网络文件系统访问不能可以版本库大小稍大稍小扩展性：修订版本树数量无限制某些本地文件系统在处理单一目录包含上千个条目时会出现问题。扩展性：文件较多的目录较慢较慢检出最新代码的速度较快可以大量提交的速度较慢，但时间被分配在整个提交操作中较快，但最后较长的延时可能会导致客户端操作超时组访问权处理对于用户的 umask 设置十分敏感，最好只由一个用户访问。对 umask 设置不敏感功能成熟时间2001 年2004 年

   确定了具体的数据存储类型，只要在命令行当中执行 svnadmin 命令就可以创建一个 Subversion 版本库，命令如下

   # 创建文件夹$ mkdir /etc/svn/$ mkdir /etc/svn/repos# 运行创建版本库的命令，指定数据存储为 FSFS，如果要指定为 Berkeley DB，则将 fsfs 替换为 bdb$ svnadmin create --fs-type fsfs /etc/svn/repos

   
   

   如果一切正常，命令执行后不会有任何反馈信息而迅速返回，这样，一个新的版本库就被创建出来了。我们来查看一下生成的版本库结构：

   $ ls -l /etc/svn/repos总用量 56drwxrwxr-x  2 robert robert 4096  8月 27 17:27 confdrwxrwxr-x  2 robert robert 4096  8月 27 17:27 davdrwxrwsr-x  5 robert robert 4096  8月 27 17:27 db-r--r--r--  1 robert robert    2  8月 27 17:27 formatdrwxrwxr-x  2 robert robert 4096  8月 27 17:27 hooksdrwxrwxr-x  2 robert robert 4096  8月 27 17:27 locks-rw-rw-r--  1 robert robert  229  8月 27 17:27 README.txt

   
   

   其中，conf 目录下存放了版本库的配置文件，包括用户访问控制和权限控制等内容，文件本身的注释说明十分详细，读者可以根据注释自行配置；dav 目录是提供给 Apache 相关模块的目录，目前为空；db 目录下存放着 Subversion 所要管理的所有受版本控制的数据，不同的存储方式（Berkeley DB 或者 FSFS）下有着不同的目录结构，不过我们一般不用直接修改和查看这个目录下的内容，Subversion 的命令可以安全的操作这个目录；另外，hooks 目录存放着钩子脚本及其模版（一种版本库事件触发程序），locks 目录存放着 Subversion 版本库锁定数据，format 文件记录了版本库的布局版本号。

   项目添加

   有了新建的版本库，就可以往里面添加项目了。不过，管理员必须考虑的问题是，应该将每一个项目分别放在不同的版本库里面，还是应该将它们放在统一的版本库里面。统一的版本库可以让管理员更加容易的升级和备份，不过，由于访问权限控制是针对整个版本库的，所以，统一的版本库也为不同项目配置不同的访问权限带来了麻烦。所以，管理员应该根据实际情况权衡考虑。

   我们以统一的版本库为例，添加两个项目 project_luni 和 project_test。要做到这个，最好的办法就是用 svn import 命令导入已有的目录树。

   首先，我们在一个临时目录下，根据 Subversion 版本控制的一般布局结构，创建出两个项目的主要目录树，如下：

   /etc/svn/tmp|――project_luni|||――branches|||――tags|||――trunk|――project_test|――branches|――tags|――trunk

   
   

   然后，用 svn import 命令来进行项目的导入：

   $ svn import /etc/svn/tmp/ file:///etc/svn/repos/ --message "init"新增           /etc/svn/tmp/project_test新增           /etc/svn/tmp/project_test/trunk新增           /etc/svn/tmp/project_test/branches新增           /etc/svn/tmp/project_test/tags新增           /etc/svn/tmp/project_luni新增           /etc/svn/tmp/project_luni/trunk新增           /etc/svn/tmp/project_luni/branches新增           /etc/svn/tmp/project_luni/tags提交后的修订版为 1。

   
   

   版本库查看

   作为版本库管理员，我们经常需要查看 Subversion 版本库的状况，这就需要一些“只读”的查看工具。

   在上述项目导入完成以后，我们可以用 svn list 确认导入的项目是否正确：

   $ svn list --verbose file:///etc/svn/repos/1 robert                 8月 27 18:24 project_luni/1 robert                 8月 27 18:24 project_test/

   
   

   另外，如果要查看最新修订版本的信息，可以使用 svnlook info 命令：

   $ svnlook info /etc/svn/repos/robert2006-08-27 18:24:27 +0800 (日, 27  8月 2006)0

   
   

   命令输出了这个版本库的最新修订版本信息，包括作者、时间、日志字数和日志内容等。除开最新修订版以外，我们还可以在命令后面接上 “--revision 版本号” 来指定某一个修订版的显示。

   另外，我们还可以用如下命令来显示版本库的具体树形结构，后面的 “--show-ids” 选项指定显示每一个显示元素的修改版本 ID。

   $ svnlook tree /etc/svn/repos/ --show-ids/ <0.0.r1/1007>project_test/ <1.0.r1/333>trunk/ <2.0.r1/0>branches/ <3.0.r1/74>tags/ <4.0.r1/152>project_luni/ <5.0.r1/793>trunk/ <6.0.r1/454>branches/ <7.0.r1/530>tags/ <8.0.r1/609>

   
   

   其他

   这里有一个需要新手，尤其是习惯了 Subversion 客户端命令 “svn” 的用户注意的问题，那就是，“svnadmin” 和 “svnlook” 都被认为是服务器端的管理工具，只被用于版本库所在的机器，用来检查和维护版本库，不能通过网络来执行任务。所以，试图将 URL 甚至本地 file 路径传递给这两个程序，都是错误的。

   Subversion 还有很多管理工具可供管理员应用，需要了解这项工具的使用方法，读者们可以用 svn help, svnadmin help, svnlook help 等等命令查看帮助信息，另外，Subversion 参考手册提供了更为全面和详细的使用介绍。

   基本的服务器配置

   Subversion 设计了一个抽象的网络层，版本库建立完毕之后，可以通过各种服务器向外公布。svnserve 是 Subversion 自带的一个小型的服务器，它使用独立的协议与客户端。我们可以通过

   svnserve –i

   
   

   作为 inetd 启动或者

   svnserve –d

   
   

   作为守护进程启动一个服务。服务器启动后，客户端即可以通过绝对路径访问。如上例可以访问 svn://服务器IP/etc/svn/repos。同时可以指定一些选项，常用的如 -r，用来指定版本库的根路径，例如假设版本库位于 /etc/svn/repos：

   svnserve –d -r /etc/svn

   
   则客户端可以通过如下 URL 访问服务器：svn://服务器IP/repos， 这样可以有效的避免暴露本地路径。另外如 --listen-port，--listen-host 可以指定绑定的地址和端口，-R 可以强制设定为 Read-Only 模式。如果在 Windows 操作系统下，可以将版本库设定在 C 分区，如 c:/svnroot/repos 可以通过 svn://服务器IP/svnroot/repos访问，如果在其他分区，就必须要通过 -r 选项来指定 root 位置。

    

   svnserve 可以通过配置 svnserve.conf 来进行一些简单的访问权限控制。你可以在版本库的 conf 子文件夹下发现这个文件。文件的初始内容大致如下：

   [general]# anon-access = read# auth-access = writepassword-db = passwd# authz-db = authz# realm = My First Repository

   
   

   其中 anon-access 表示匿名用户的权限，auth-access 表示认证用户的权限设置，password-db 指向保存用户帐号密码的文件的位置，可以使用相对路径。svnserve 只能对全局提供简单的访问控制，如果想要更加灵活的方式，可以使用 Apache Http Server 作为向外公布版本库的方式。

   与 Apache Http Server 的结合

   通过 Http 协议访问版本库是 Subversion 的亮点之一。使用 Http 协议意味着只需要打开浏览器，输入 URL 即可轻松的浏览整个版本库。灵活通常带来复杂性，Http 方式相对于 svnserve 方式来说需要更多的配置。

   由于 Subversion 需要版本化的控制，因此标准的 Http 协议不能满足需求。要让 Apache 与 Subversion 协同工作，需要使用 WebDAV（Web 分布式创作和版本控制）。WebDAV 是 HTTP 1.1 的扩展，关于 WebDAV 的规范和工作原理，可以参考 IETF RFC 2518。

   为了使 Subversion 与 dav 模块通信，需要安装 mod_dav_svn 插件，可以在 Subversion 的安装目录中找到。将其拷贝到 Apache 安装目录的 modules 文件夹下。接下来就是配置 Apache 的 httpd.conf 文件，让 Apache 在启动的时候加载上述模块。

   需要添加的内容如下：

   LoadModule dav_module modules/mod_dav.soLoadModule dav_svn_module modules/mod_dav_svn.so<Location /repos>  DAV svn  SVNPath /etc/svn/repos</Location>

   
   

   首先需要启用 dav_module，然后加载 dav_svn_module。Location 标签指出访问的 URL 以及在服务器上的实际位置。配置完毕后重新启动 Apache，打开浏览器，输入 http://服务器IP/repos 将会看到如下画面：

   
   图1. 一个初始版本库
    
   

   这表示 Apache 的 dav_svn 模块已经可以正常工作了。用户可以使用任何一种 Subversion 的客户端通过 Http 协议访问你的版本库。

   如果想要指定多个版本库，可以用多个 Location 标签，也可以使用 SVNParentPath 代替 SVNPath，例如在 /etc/svn 下有多个版本库 repos1，repos2 等等，用如下方式指定：

   <Location /repos>  DAV svn  SVNParentPath /etc/svn</Location>

   
   

   "SVNParentPath /etc/svn" 表示 /etc/svn 下的每个子目录都是一个版本库。可以通过 http://服务器IP/repos/repos1，http://服务器IP/repos/repos2 来访问。

   现在你的版本库任何人都可以访问，并且有完全的写操作权限。也就是说任何人都可以匿名读取，修改，提交，以及删除版本库中的内容。显然大部分场合这是不符合需求的。那么如何进行权限设置呢，Apache 提供了基本的权限设置：

   首先需要创建一个用户文件。Apache 提供了一个工具 htpasswd，用于生成用户文件，可以在 Apache 的安装目录下找到。具体使用方法如下：

   htpasswd etc/svn/passwordfile username

   
   

   如果 passwordfile 不存在，可以加上 -c 选项让 htpasswd 新建一个。创建好的文件内容是用户名加上密码的 MD5 密文。

   接下来修改 httpd.conf，在 Location 标签中加入如下内容：

   AuthType BasicAuthName "svn repos"AuthUserFile /etc/svn/passwordfileRequire valid-user

   
   

   重新启动 Apache， 打开浏览器访问版本库。Apache 会提示你输入用户名和密码来认证登陆了，现在只有 passwordfile 文件中设定的用户才可以访问版本库。也可以配置只有特定用户可以访问，替换上述 "Require valid-user" 为 "Require user tony robert" 将只有 tony 和 robert 可以访问该版本库。

   有的时候也许不需要这样严格的访问控制，例如大多数开源项目允许匿名的读取操作，而只有认证用户才允许写操作。为了实现更为细致的权限认证，可以使用 Limit 和 LimitExcept 标签。例如：

   <LimitExcept GET PROPFIND OPTIONS REPORT>require valid-user</LimitExcept>

   
   

   如上配置将使匿名用户有读取权限，而限制只有 passwordfile 中配置的用户可以使用写操作。如果这还不能满足你的要求，可以使用 Apache 的 mod_authz_svn 模块对每个目录进行认证操作。

   用 mod_authz_svn 进行目录访问控制

   首先需要让 Apache 将 mod_authz_svn 模块加载进来。在 Subversion 的安装目录中找到 mod_auth_svn 模块，将其拷贝到 Apache 安装目录的 modules 子目录下。修改 httpd.conf 文件，找到

   LoadModule dav_svn_module modules/mod_dav_svn.so

   
   

   在其后面加上

   LoadModule authz_svn_module modules/mod_authz_svn.so

   
   

   现在可以在 Location 标签中使用 authz 的功能了。一个基本的 authz 配置如下：

   <Location /repos>  DAV svn   SVNPath /etc/svn/repos   AuthType Basic   AuthName "svn repos"   AuthUserFile /etc/svn/passwd   AuthzSVNAccessFile /etc/svn/accesspolicy  Satisfy Any   Require valid-user </Location>

   
   

   AuthzSVNAccessFile 指向的是 authz 的策略文件，详细的权限控制可以在这个策略文件中指定，如：

   #两个分组：committers，developers[groups] committers = paulex richarddevelopers = jimmy michel spark sean /            steven tony robert#在根目录下指定所有的用户有读权限[/] * = r #追加 committers 组用户有读写权限@committers = rw #在 branches/dev 目录下指定 developers 组的用户有读写权限[/branches/dev] @developers = rw #在 /tags 组下给予用户 tony 读写权限[/tags] tony = rw #禁止所有用户访问 /private 目录[/private] * = #给 committers 组用户读权限@committers= r

   
   

   使用 SVNParentPath 代替 SVNPath 来指定多个版本库的父目录时，其中所有的版本库都将按照这个策略文件配置。例如上例中 tony 将对所有版本库里的 /tags 目录具有读写权限。如果要对具体每个版本库配置，用如下的语法：

   [groups] project1_committers = paulex richardproject2_committers = jimmy michel spark sean /            steven tony robert[repos1:/] * = r @ project1_committer = rw [repos2:/] * = r @ project2_committer = rw 

   
   

   这样项目1的 committer 组只能对 repos1 版本库下的文件具有写权限而不能修改版本库 repos2，同样项目2的 commiter 也不能修改 repos1 版本库的文件。

   用 MySQL 代替文件形式存放密码

   到目前为止我们的用户名密码文件还是以文本文件形式存放在文件系统中的，出于安全性的需要或者单点登陆等可扩展性的考虑，文本文件的管理方式都不能满足需求了。通过 Apache 的 module_auth_mysql 模块，我们可以用 MySQL 来保存用户信息。该模块的主页在 http://modauthmysql.sourceforge.net/，你也可以在http://modules.apache.org/ 找到它的发行版本。安装方法同上述 Apache 的模块一样，拷贝至 modules 目录并在 httpd.conf 文件中添加如下语句：

   LoadModule mysql_auth_module modules/mod_auth_mysql.so

   
   

   相应的 Location 区域改写为：

   <Location /repos>   AuthName "MySQL auth"   AuthType Basic   AuthMySQLHost localhost   AuthMySQLCryptedPasswords Off  AuthMySQLUser root  AuthMySQLDB svn   AuthMySQLUserTable users  require valid-user </Location>

   
   

   然后在 mysql 中添加名为 svn 的数据库，并建立 users 数据表：

   create database svn;use svn;CREATE TABLE users (user_name CHAR(30) NOT NULL,user_passwd CHAR(20) NOT NULL,user_group CHAR(10),PRIMARY KEY (user_name));

   
   

   在 users 表中插入用户信息

   insert into users values('username','password','group');

   
   

   重新启动 Apache，在访问版本库的时候 Apache 就会用 mysql 数据表中的用户信息来验证了。

   用 SSL 实现安全的网络传输

   通过 Apache 的网络链接，版本库中的代码和数据可以在互联网上传输，为了避免数据的明文传输，实现安全的版本控制，需要对数据的传输进行加密。Apache 提供了基于 SSL 的数据传输加密模块 mod_ssl，有了它，用户就可以用 https 协议访问版本库，从而实现数据的加密传输了。SSL 协议及其实现方式，是一个非常复杂的话题，本文只是介绍 Apache 提供的最基本的SSL配置方法，更加详细的介绍内容，请参考 http://httpd.apache.org/docs-2.0/ssl/ 上的文档。

   开始配置前，我们需要一个实现 Apache 中 SSL 模块的动态程序库，通常名为 mod_ssl.so，及其配置文件，通常名为 ssl.conf。这个实现是跟 Apache 的版本相关的，不匹配的版本是不能用的；而且，并不是每一个 Apache 的版本都自带了相关实现文件，很多情况下，我们需要自己去搜寻相关文件。另外，我们还需要 OpenSSL 软件及其配置文件，来生成加密密钥和数字证书。这里，我们可以使用一些免费网站，如 http://hunter.campbus.com/ 上提供的集成版本的 Apache。

   有了相关的工具和文件，我们就可以开始生成 SSL 的证书和密钥了。首先，我们需要找到 openssl 程序及其配置文件 openssl.cnf，运行如下命令来生成 128 位的 RSA 私有密钥文件

   my-server.key：openssl genrsa -des3 -out my-server.key 1024Loading 'screen' into random state - doneGenerating RSA private key, 1024 bit long modulus.....++++++........++++++e is 65537 (0x10001)Enter pass phrase for server.key:********Verifying - Enter pass phrase for server.key:********

   
   

   命令运行期间需要用户输入并确认自己的密码。

   现在，我们需要 SSL 的认证证书，证书是由 CA（certificate authority） 发放并且认证的。为此，我们可以用如下命令生成一个 CSR(Certificate Signing Request) 文件发给 CA，从而得到 CA 的认证：

   openssl req -new -key my-server.key -out my-s erver.csr -config openssl.cnf

   
   

   当然，一般情况下，如果 Subversion 的用户不是太多，安全情况不是很复杂，我们也可以生成一个自签名的认证证书，从而省去了向 CA 申请认证的麻烦。如下命令：

   openssl req -new -key my-server.key -x509 -out my-server.crt -config openssl.cnf

   
   

   以上两个命令都需要用户输入那个 key 文件的密码，以及一些网络设置信息，如域名，邮箱等等，这里输入的服务器域名应该与 Apache 配置文件当中的一致。现在，我们可以在 Apache 的 conf 目录下新建一个 ssl 目录，将 my-server.key 和 my-server.crt 文件都移动到 ssl 目录里面。然后修改 ssl.conf 文件，将 SSLCertificateKeyFile 和 SSLCertificateFile 项指向这两个文件。

   如果 Apache 的 module 目录里面没有 mod_ssl.so 文件，可以将事先准备好的文件拷贝过去。然后，我们可以设置 Apache 的配置文件 httpd.conf，将 ssl 模块加入其中：

   LoadModule ssl_module modules/mod_ssl.so

   
   

   然后，在配置文件的最后，加上如下 SSL 相关配置项：

   SSLMutex defaultSSLRandomSeed startup builtinSSLSessionCache noneErrorLog logs/SSL.logLogLevel info<VirtualHost svntest.ut.cn.ibm.com:443>  SSLEngine On  SSLCertificateFile conf/ssl/my-server.crt  SSLCertificateKeyFile conf/ssl/my-server.key</VirtualHost>

   
   

   这样，基本的设置工作就完成了。重新启动 Apache 服务器，现在可以用 https 协议代替 http 协议来访问版本库了。如果要限定版本库只能用 https 访问，我们可以在 Apache 配置文件当中 Subversion 部分加上 “SSLRequireSSL”。如下：

   <Location /repos>  DAV svn   SVNPath /etc/svn/repos  ………….#other items  SSLRequireSSL </Location>

   
   

   总结

   Subversion 以其优良的版本控制功能，灵活的网络访问模型，以及与 Apache 服务器联合配置所带来的更强大的管理控制功能，逐渐在开源软件开发的实践当中得到广泛的应用。本文重点介绍了 Subversion 服务器端的配置以及与 Apache 服务器联合配置的基本步骤和简单应用，实现了简单的实例应用。读者如果想要进一步了解相关信息，请参考文章后面列出的相关资料。

   
   
   

   参考资料

   • Subversion 官方网站：Subversion 的发源地，提供最权威的介绍和最新的下载。
     
   • Subclipse 官方网站：Subversion 配套的插件站点，提供 Eclipse 中 Subversion 的插件下载和文档。
     
   • Subversion 手册：官方提供的全面而细致的使用说明书。
     
   • IETF RFC 2518 WebDAV 的规范和工作原理的原始文档。 
     
   • Subversion 简介：developerWorks Java 专区中的一篇介绍 Subversion 客户端插件使用方法的文章 (Elliotte Harold，developWorks 2006 年 7 月 06 日)。 
     
   • 用 Subversion 构建版本控制环境 ：developerWorks Java 专区中的一篇介绍 Subversion 客户端安装，配置，插件使用的文章 (刘冬，developWorks 2005 年 9 月)