如果項目創(chuàng)建了維護分支 /branches/1.x ，若和 /trunk 授權(quán)相同，則需要將上述授權(quán)在 /branches/1.x 下重建。需要在授權(quán)文件中再添加如下授權(quán)指令：
[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
如果版本庫的分支和里程碑越來越多，配置的工作量相當可觀，稍有不慎不是授權(quán)文件格式破壞導致SVN無法工作， 是造成開放授權(quán)。
我曾經(jīng)寫過SVN路徑授權(quán)的補丁，并寫了一款SVN版本庫管理的開源軟件 （參見 《pySvnManager手冊》 ）， 但想完美解決這個問題很難。我的一個設(shè)想是在SVN對分支和里程碑授權(quán)檢查時缺省使用 /trunk 的授權(quán)，但這樣的實現(xiàn)要求使用SVN嚴格遵循約定俗成的三個目錄的規(guī)范。
Git對于寫操作可以精細到目錄和分支級別（使用Gitolite作為服務(wù)器）， 但作為分布式版本庫控制系統(tǒng)，在設(shè)計上只能實現(xiàn)版本庫量子化的讀授權(quán)。 即某用戶對整個版本庫要么都能讀，要么對整個版本庫都不能讀。
那么如何控制Git版本庫的讀授權(quán)呢？實際上Git可以通過子模組來實現(xiàn)細粒度的讀授權(quán)。 即在項目需要精細授權(quán)的場合，將版本庫拆分為多個Git版本庫進行單獨授權(quán)， 再使用子模組將多個版本庫整合為一個。這個操作并不復雜，而且有助于實現(xiàn)項目的模塊化。
誤解3：Git能隨意改變歷史提交，這對于版本控制來說是不合適的
Git對歷史提交的修改只對本地提交有意義。本地提交像是和共享版本庫間的緩沖。 在未將本地提交推送到遠程共享版本庫之前，開發(fā)者可以后悔�？梢詫Σ煌暾奶峤徽f明進行補充， 可以移除錯誤的提交，可以壓縮合并提交等。Git對提交歷史靈活的操作是Git獨有的功能， 是提交審核的必備工具。
對于已經(jīng)推送到遠程共享服務(wù)器的提交，Git不能再像本地一樣隨意更改了。 因為推送到共享版本庫的提交一旦被其他程序員獲取，便擴散出去， 如覆水難收，難掩眾人悠悠之口。所以Git更改歷史提交只對本地有效，是安全的。
相比之下，SVN本地工作區(qū)和集中式版本庫之間沒有緩沖，一旦發(fā)現(xiàn)提交了錯誤內(nèi)容， 或?qū)懥隋e誤的提交說明，則無法更改，除非SVN管理員介入。 SVN也允許配置為可修改歷史提交說明，但是一旦管理員放開此功能， 歷史提交的提交說明有可能被批量、惡意更改，并且無法恢復。
誤解4：SVN對中文支持更好，Git庫中的中文目錄和文件名會出現(xiàn)亂碼
我也曾經(jīng)這么認為，并在《Git權(quán)威指南》第3章中用了大量篇幅介紹中文支持的注意事項。 并推薦使用Cygwin作為客戶端，以避免GBK字符集為跨平臺開發(fā)的版本庫引入亂碼。
一個好消息是Windows下常用的Git客戶端 msysGit 也支持Unicode了。 使用新版本（1.7.10）的 msysGit 無需設(shè)置任何Git配置變量， 版本庫中的中文文件名、目錄名、提交說明都使用Unicode編碼。 配合使用Unicode版的TortoiseGit（新的1.7.9.0版本已是Unicode版）， Windows用戶不再為跨平臺開發(fā)的字符集問題而傷腦筋了。
誤解5：SVN的認證方式比Git豐富，比如可以實現(xiàn)LDAP認證
我為客戶配置的Git支持HTTP、SSH協(xié)議，和Gitweb。其中HTTP協(xié)議、Gitweb都使用LDAP認證， 實現(xiàn)統(tǒng)一的口令管理。并且無論是HTTP協(xié)議、SSH協(xié)議，還是Gitweb都使用同一套Gitolite授權(quán)。
誤解6：SVN更易上手，更易管理；而Git太難和太靈活了，不適合團隊？
如果想把配置管理做好，無論是 SVN 還是 Git 都不容易，否則 《SVN Book》 以及我寫 《Git權(quán)威指南》 也不會有那么厚了。
覺得SVN更簡單的，看看下面的錯誤你有沒有犯？
● 很多公司的SVN版本庫沒有遵照約定俗成的三個目錄。
● 如何配置SVN悲觀鎖，以便更好地對二進制文件編輯進行協(xié)同。
● 維護合并追蹤的 svn:mergeinfo 屬性，以便能夠正確的分支合并。還要防止無此功能的客戶端對其的破壞。
● SVN如何正確的反刪除，直接添加刪除的文件是不對的。
● 如何使用 svn:eol-style 屬性，以便正確處理跨平臺開發(fā)時的文件換行符問題。
● SVN管理員如何對版本庫進行整理，如撤出不當提交、修改錯誤的提交說明。
● 版本庫的安全性問題，如何做好版本庫的備份。
