用户组格式：
[groups]
groupname=user1 ,user2,user3
其中，1个用户组可以包含1个或多个用户，用户间以逗号分隔。
版本库目录格式：
[<版本库>:/项目/目录]
@<用户组名> = <权限>
<用户名> = <权限>
其中，方框号内部分可以有多种写法:
[/],表示根目录及以下，根目录是svnserve启动时指定的，我们指定为/home/svn/test，[/]就是表示对全部版本库设置权限。
[repos:/] 表示对版本库repos设置权限；
[repos:/abc] 表示对版本库repos中的abc项目设置权限；
[repos:/abc/aaa] 表示对版本库repos中的abc项目的aaa目录设置权限；
权限主体可以是用户组、用户或*，用户组在前面加@，*表示全部用户。
权限可以是w、r、wr和空，空表示没有任何权限。
ex:
[/]
@groupname = rw
svn+apache的配置文件无非就是subversion.conf有关apache的给svn的模块配置) authz（用户角色权限配置）
passwd（用户密码）
passwd无非就是新建用户或者修改密码用。
authz相对较为复杂，下面举个例子
[group]
admin = aaa,bbb,ccc
vip = a1
man = b1
custom = c1 //这里先设定有这么多个角色和用户
//假设库的名字叫cp
//下面在cp下建立2个平行的目录vip和main
[/]
@admin=rw //表示根目录下只有admin才有读写权限
[cp:/]
*=r //在cp库下，除了admin下，所有人都有读的权限
@admin=rw //在cp库下，admin具有读写的权限
[cp:/vip]
*= //除了vip和admin之外，所有人没有任何权限
@vip=rw //
@admin=rw //
[cp:/main]
*= //除了以下角色外，其他人没有任何权限
@admin=rw //
@vip=rw //
@man=r //
如果出现有的目录下有子目录的话，那么在目录中有权限的角色在子目录中也应该有相应角色权限。
也就是说，子目录可以继承母目录的角色权限。
比如 vip这个目录下面有vip1这个目录，那么vip和admin依然有对vip1进行rw的权限。
3.15补充
@admin=rw //表示根目录下只有admin才有读写权限
[cp:/]
*=r //在cp库下，除了admin下，所有人都有读的权限
@admin=rw //在cp库下，admin具有读写的权限
[cp:/vip]
*= //除了vip和admin之外，所有人没有任何权限
@vip=rw //
@admin=rw //
[cp:/main]
*= //除了以下角色外，其他人没有任何权限
@admin=rw //
@vip=rw //
@man=r //
[cp:/main/01-aaa] //admin和test能访问，admin能看到，vip用户是看不到有这个目录的
@test=rw
@admin=rw
这里补充一下，目录中还有目录特别设置权限的话，如果上一级用户拥有权限但是没有拥有特定的这个权限的话，是看不到的该文件夹的。或者说，拥有子目录权限但是没有主目录权限的话，可以直接通过完全的子目录链接来达到访问的目的。
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”菜单将文件转换成本地编码，通常是GB2312码，然后再使用“ASCII TO UTF-8(UNICODE Editing)”来转换到 UTF-8 即可。