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