如果项目创建了维护分支 /branches/1.x ，若和 /trunk 授权相同，则需要将上述授权在 /branches/1.x 下重建。需要在授权文件中再添加如下授权指令：
[demo:/branches/1.x]
@demo-admin = rw
@leaders = r
[demo:/branches/1.x/doc]
@demo-dev = rw
@designers = rw
[demo:/branches/1.x/src/apps]
@demo-dev = rw
[demo:/branches/1.x/src/common]
@demo-dev = rw
[demo:/branches/1.x/src/html]
@designers = rw
[demo:/branches/1.x/src/secret]
* =
@demo-admin = rw
jiangxin = rw
如果版本库的分支和里程碑越来越多，配置的工作量相当可观，稍有不慎不是授权文件格式破坏导致SVN无法工作， 是造成开放授权。
我曾经写过SVN路径授权的补丁，并写了一款SVN版本库管理的开源软件 （参见 《pySvnManager手册》 ）， 但想完美解决这个问题很难。我的一个设想是在SVN对分支和里程碑授权检查时缺省使用 /trunk 的授权，但这样的实现要求使用SVN严格遵循约定俗成的三个目录的规范。
Git对于写操作可以精细到目录和分支级别（使用Gitolite作为服务器）， 但作为分布式版本库控制系统，在设计上只能实现版本库量子化的读授权。 即某用户对整个版本库要么都能读，要么对整个版本库都不能读。
那么如何控制Git版本库的读授权呢？实际上Git可以通过子模组来实现细粒度的读授权。 即在项目需要精细授权的场合，将版本库拆分为多个Git版本库进行单独授权， 再使用子模组将多个版本库整合为一个。这个操作并不复杂，而且有助于实现项目的模块化。
误解3：Git能随意改变历史提交，这对于版本控制来说是不合适的
Git对历史提交的修改只对本地提交有意义。本地提交像是和共享版本库间的缓冲。 在未将本地提交推送到远程共享版本库之前，开发者可以后悔。可以对不完整的提交说明进行补充， 可以移除错误的提交，可以压缩合并提交等。Git对提交历史灵活的操作是Git独有的功能， 是提交审核的必备工具。
对于已经推送到远程共享服务器的提交，Git不能再像本地一样随意更改了。 因为推送到共享版本库的提交一旦被其他程序员获取，便扩散出去， 如覆水难收，难掩众人悠悠之口。所以Git更改历史提交只对本地有效，是安全的。
相比之下，SVN本地工作区和集中式版本库之间没有缓冲，一旦发现提交了错误内容， 或写了错误的提交说明，则无法更改，除非SVN管理员介入。 SVN也允许配置为可修改历史提交说明，但是一旦管理员放开此功能， 历史提交的提交说明有可能被批量、恶意更改，并且无法恢复。
误解4：SVN对中文支持更好，Git库中的中文目录和文件名会出现乱码
我也曾经这么认为，并在《Git权威指南》第3章中用了大量篇幅介绍中文支持的注意事项。 并推荐使用Cygwin作为客户端，以避免GBK字符集为跨平台开发的版本库引入乱码。
一个好消息是Windows下常用的Git客户端 msysGit 也支持Unicode了。 使用新版本（1.7.10）的 msysGit 无需设置任何Git配置变量， 版本库中的中文文件名、目录名、提交说明都使用Unicode编码。 配合使用Unicode版的TortoiseGit（新的1.7.9.0版本已是Unicode版）， Windows用户不再为跨平台开发的字符集问题而伤脑筋了。
误解5：SVN的认证方式比Git丰富，比如可以实现LDAP认证
我为客户配置的Git支持HTTP、SSH协议，和Gitweb。其中HTTP协议、Gitweb都使用LDAP认证， 实现统一的口令管理。并且无论是HTTP协议、SSH协议，还是Gitweb都使用同一套Gitolite授权。
误解6：SVN更易上手，更易管理；而Git太难和太灵活了，不适合团队？
如果想把配置管理做好，无论是 SVN 还是 Git 都不容易，否则 《SVN Book》 以及我写 《Git权威指南》 也不会有那么厚了。
觉得SVN更简单的，看看下面的错误你有没有犯？
● 很多公司的SVN版本库没有遵照约定俗成的三个目录。
● 如何配置SVN悲观锁，以便更好地对二进制文件编辑进行协同。
● 维护合并追踪的 svn:mergeinfo 属性，以便能够正确的分支合并。还要防止无此功能的客户端对其的破坏。
● SVN如何正确的反删除，直接添加删除的文件是不对的。
● 如何使用 svn:eol-style 属性，以便正确处理跨平台开发时的文件换行符问题。
● SVN管理员如何对版本库进行整理，如撤出不当提交、修改错误的提交说明。
● 版本库的安全性问题，如何做好版本库的备份。
