如果項(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ù)的分支和里程碑越來越多，配置的工作量相當(dāng)可觀，稍有不慎不是授權(quán)文件格式破壞導(dǎo)致SVN無法工作， 是造成開放授權(quán)。

我曾經(jīng)寫過SVN路徑授權(quán)的補(bǔ)丁，并寫了一款SVN版本庫(kù)管理的開源軟件 （參見 《pySvnManager手冊(cè)》 ）， 但想完美解決這個(gè)問題很難。我的一個(gè)設(shè)想是在SVN對(duì)分支和里程碑授權(quán)檢查時(shí)缺省使用 /trunk 的授權(quán)，但這樣的實(shí)現(xiàn)要求使用SVN嚴(yán)格遵循約定俗成的三個(gè)目錄的規(guī)范。

Git對(duì)于寫操作可以精細(xì)到目錄和分支級(jí)別（使用Gitolite作為服務(wù)器）， 但作為分布式版本庫(kù)控制系統(tǒng)，在設(shè)計(jì)上只能實(shí)現(xiàn)版本庫(kù)量子化的讀授權(quán)。 即某用戶對(duì)整個(gè)版本庫(kù)要么都能讀，要么對(duì)整個(gè)版本庫(kù)都不能讀。

那么如何控制Git版本庫(kù)的讀授權(quán)呢？實(shí)際上Git可以通過子模組來實(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ì)于版本控制來說是不合適的

Git對(duì)歷史提交的修改只對(duì)本地提交有意義。本地提交像是和共享版本庫(kù)間的緩沖。 在未將本地提交推送到遠(yuǎn)程共享版本庫(kù)之前，開發(fā)者可以后悔�？梢詫�(duì)不完整的提交說明進(jìn)行補(bǔ)充， 可以移除錯(cuò)誤的提交，可以壓縮合并提交等。Git對(duì)提交歷史靈活的操作是Git獨(dú)有的功能， 是提交審核的必備工具。
      對(duì)于已經(jīng)推送到遠(yuǎn)程共享服務(wù)器的提交，Git不能再像本地一樣隨意更改了。 因?yàn)橥扑偷焦蚕戆姹編?kù)的提交一旦被其他程序員獲取，便擴(kuò)散出去， 如覆水難收，難掩眾人悠悠之口。所以Git更改歷史提交只對(duì)本地有效，是安全的。
      相比之下，SVN本地工作區(qū)和集中式版本庫(kù)之間沒有緩沖，一旦發(fā)現(xiàn)提交了錯(cuò)誤內(nèi)容， 或?qū)懥隋e(cuò)誤的提交說明，則無法更改，除非SVN管理員介入。 SVN也允許配置為可修改歷史提交說明，但是一旦管理員放開此功能， 歷史提交的提交說明有可能被批量、惡意更改，并且無法恢復(fù)。

誤解4：SVN對(duì)中文支持更好，Git庫(kù)中的中文目錄和文件名會(huì)出現(xiàn)亂碼

我也曾經(jīng)這么認(rèn)為，并在《Git權(quán)威指南》第3章中用了大量篇幅介紹中文支持的注意事項(xiàng)。 并推薦使用Cygwin作為客戶端，以避免GBK字符集為跨平臺(tái)開發(fā)的版本庫(kù)引入亂碼。
     一個(gè)好消息是Windows下常用的Git客戶端 msysGit 也支持Unicode了。 使用新版本（1.7.10）的 msysGit 無需設(shè)置任何Git配置變量， 版本庫(kù)中的中文文件名、目錄名、提交說明都使用Unicode編碼。 配合使用Unicode版的TortoiseGit（新的1.7.9.0版本已是Unicode版）， Windows用戶不再為跨平臺(tái)開發(fā)的字符集問題而傷腦筋了。

誤解5：SVN的認(rèn)證方式比Git豐富，比如可以實(shí)現(xiàn)LDAP認(rèn)證

我為客戶配置的Git支持HTTP、SSH協(xié)議，和Gitweb。其中HTTP協(xié)議、Gitweb都使用LDAP認(rèn)證， 實(shí)現(xiàn)統(tǒng)一的口令管理。并且無論是HTTP協(xié)議、SSH協(xié)議，還是Gitweb都使用同一套Gitolite授權(quán)。

誤解6：SVN更易上手，更易管理；而Git太難和太靈活了，不適合團(tuán)隊(duì)？

如果想把配置管理做好，無論是 SVN 還是 Git 都不容易，否則 《SVN Book》 以及我寫 《Git權(quán)威指南》 也不會(huì)有那么厚了。

覺得SVN更簡(jiǎn)單的，看看下面的錯(cuò)誤你有沒有犯？

● 很多公司的SVN版本庫(kù)沒有遵照約定俗成的三個(gè)目錄。

● 如何配置SVN悲觀鎖，以便更好地對(duì)二進(jìn)制文件編輯進(jìn)行協(xié)同。

● 維護(hù)合并追蹤的 svn:mergeinfo 屬性，以便能夠正確的分支合并。還要防止無此功能的客戶端對(duì)其的破壞。

● SVN如何正確的反刪除，直接添加刪除的文件是不對(duì)的。

● 如何使用 svn:eol-style 屬性，以便正確處理跨平臺(tái)開發(fā)時(shí)的文件換行符問題。

● SVN管理員如何對(duì)版本庫(kù)進(jìn)行整理，如撤出不當(dāng)提交、修改錯(cuò)誤的提交說明。

● 版本庫(kù)的安全性問題，如何做好版本庫(kù)的備份。