配置svn服务器

配置svn服务器
假如你对我们如何配置SVN的服务器，以及它的权限治理如何设置感爱好，欢迎你阅读下面的部分，那个地点仅仅对第一节当中阐述的svn+ssh，且使用密钥对认证的方式进行说明。

期望我们以后有更多的同学能够承担服务器的爱护工作。

那个地点我们假设你差不多比较熟悉Linux上的一些差不多操作，否则的话请去补习一下 ^_^
1、创建独立的svn版本库属主，也确实是前面提到过的svnowner。

我们期望svnowner自己是一个独立的用户，同时也独立成组，如此能够幸免不必要的外人干扰。

以下的操作除非专门说明，均使用svnowner用户进行操作。

2、以svnowner用户的身份创建版本库。

第一使用umask 027的方式设置掩码值，使得之后创建的文件和名目对本组用户只有读权限，组外用户无权限。

假如考虑更严格的权限操纵，能够使用umask 077方式，仅承诺svnowner用户自己访问，拒绝本组、组外用户的任何访问。

接着用svnadmin create
path_for_repository在path_for_repository路径上创建版本库。

从便利和权限一致性的角度，建议把svn、svnserve、svnadmin、svnlook等svn工具改名为real_svnxxx，再创建svn等脚本程序，例如svn脚本能够如此编写：
#!/bin/bash
umask 027
/usr/bin/real_svn “$@”
3、创建SSH公钥存放文件。

在svnowner用户名目下创建.ssh名目，并在其下创建authorized_keys文件，名目和文件的都应当仅仅是本用户可读写的。

将各用户发送给你的公钥添加到authorized_keys文件当中，注意：一行一个公钥，并在公钥前增加option字段，例如：
command="/home/svnowner/svnserve -t -r path_for_repository –tunnel-user= svnuser1", no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
ssh-rsa .......(RSA Key here)er1
上例当中，用户user1使用该密钥对认证之后将会执行/home/svnowner下的svnserve，明显这应当是一个包含设置umask的脚本，同时以
path_for_repository 作为版本库的根，svnserve运行于tunnel模式下，使用的svn用户名是svnuser1。

再次提醒大伙儿的是以上内容需要在
authorized_keys里面一行内写完。

4、现在能够在版本库里面设置具体的svnuser的权限了。

进入之前所创建的path_for_repository名目，在其中有conf名目，是负责配置版本库的设置的。

找到svnserve.conf文件，在其中去掉注释并修改的行有：
anon-access = none
auth-access = write
authz-db = authz
realm = XXX Group Repository
说明匿名用户无访问权限，认证用户能够具备写权限，版本库标识为“XXX Group Repository”（此项可选），权限认证数据库是authz文件。

因此再修改authz文件，示例：
[groups]
manager = svnuser1
members = svnuser2, svnuser3
[/]
@manager = rw
* = r
[/src]
@members = r
@manager = rw
* =
[/src/arm7]
svnuser2 = rw
@manager = rw
svnuser3 = r
* =
[/src/arm9]
svnuser3 = rw
@manager = rw
svnuser2 = r
* =
[/shared]
@members = rw
以上示例的目的是将所有的名目置于manager可读写的方式，members用户能够对src名目具有可读权限，svnuser2和svnuser3分别对src/下的ARM7、ARM9名目具有读写权限，三个用户均能够对/shared名目进行读写。

匿名用户（其他用户）只能对/shared名目进行读操作。

注意：名目路径均以
path_for_repository作为根名目，这一点需要牢记。

SVN 的一个明显的优点是能够针对单个名目具备独立的操纵权限，这是比cvs更灵活的方面。

同时，这也专门适宜在团队如此的大范畴内推广、且具有可控保密措施的实施方案。

更详细的一个权限示例建议大伙儿参考由“郑新星
<zhengxinxing@gmail >”所写的《Subversion之路——实现精细的名目访问权限操纵》。

至此，Subversion服务器的搭建工作完毕，治理员的后续爱护工作包括同意组内用户密钥对的更换、删除，为Subversion作定期备份等等。

本文也暂告一段落
独立运行的Subversion权限设置专门简单，第一打开snvserve.conf，去掉下面一行的注释
authz-db = authz
然后打开同一名目下的authz那个文件，那个文件便是整个权限操纵的核心，先来看一个例子：
[groups]
dev-group = liudong,xfliang
design-group = newidea
[/]
@dev-group = rw
@design-group = r
* =
[/doc]
@design-group = rw
[/webapp]
@design-group = rw
接下来我给大伙儿说明一下那个文件，相信就能够明白Subversion如何来做权限操纵的了。

第一我定义了两个组，一个开发组(dev-group)，一个设计组(design-group)，接下来我让dev-group对整个名目有读写的权限，而design-group只有读权限。

然而接下来的两个子名目design-group就有读写权限，也确实是说设计组能够读取整个项目，但只能修改doc以及webapp这两个子名目。

*= 这行表示其他人不能读写。

因此也能够直截了当指定某个用户，例如我想让liudong那个用户能够读写webapp名目，那设置如下：
[/webapp]
@design-group = rw
liudong = rw
另外有一点注意的是，修改那个文件不需要重新启动svn服务，这点太棒了。

下面是详细的说明Subversion自带的authz样例中的注释
### This file is an example authorization file for svnserve.
### Its format is identical to that of mod_authz_svn authorization
### files.
### As shown below each section defines authorizations for the path and
### (optional) repository specified by the section name.
### The authorizations follow. An authorization line can refer to a
### single user, to a group of users defined in a special [groups]
### section, or to anyone using the '*' wildcard. Each definition can
### grant read ('r') access, read-write ('rw') access, or no access
### ('').
svn权限设置小结及“无权打开根进行编辑操作”的解决
假如不承诺匿名用户访问，设置
在svnserve.conf中进行了如此的设置：
anon-access = none
auth-access = write
假如，anon-access = read，需要在在authz文件中加上：
[/]
* = r
否则在使用SVN进行Checkout时显现错误提示：无权打开根进行编辑操作。

1. svnserve支持面向名目的访问操纵了；
2. 权限具备继承性，因此需要用"* = "的形式来禁止未授权的用户访问特定子名目；
3. svn 1.3.2及以后的版本承诺对子名目进行操作而无需父名目的读权限；
4. 假如是中文名目的话，authz必须以utf-8的格式储存，且不能带BOM，而windows 自带的记事本按utf-8储存的文件则会加上BOM，因此，假如你以utf-8格式储存好后，提交代码时，svn报"section header expected"的错时，则多半是带BOM的。

因此现在专门多编辑器都能专门方便的转换了，如ultraedit的储存为U8-DOS，editplus储存为utf-8，以及开源的Notepad++的格式转换中的“转换为utf-8码(无BOM)”等都能够完成那个工作。