如果項目創建了維護分支 /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管理員如何對版本庫進行整理，如撤出不當提交、修改錯誤的提交說明。
● 版本庫的安全性問題，如何做好版本庫的備份。
