IC項目中svn使用經驗總結

以下僅用於個人建議。

一、 svn權限

• svn用戶
• svn目錄各層次

兩者在svn工具裏權限設置及其方便簡單。
經驗：

• 權限設置太細。svn管理會太繁瑣；svn使用者遇到項目設計問題很難debug。
• 極其敏感的公共文件，設置可寫權限即可。

二、 svn分支

• trunk
• tags
• branches

這三個基本夠用了。工作流程有幾種，個人推薦
trunk是較穩定版本；branches穩定後merge到trunk，這裏只會出現因爲merge導致的錯誤或者系統級仿真錯誤。一般不會出現編譯錯誤。
branches是成員的維護版本；隨便提交，允許出現編譯錯誤，不會影響其他成員。
tags是穩定版本，跑過全部測試集。

三、 項目中遇到的問題總結

基本原則：

• svn使用者，儘量不受權限束縛。可以靈活處理各種項目問題，以避免出問題，只能求助svn管理員。
• svn tags必須保證穩定性。方便項目設計的回顧。
• svn分支，做到最簡單直接有效。svn制定的規則越多，管理越混亂。儘量使用svn官方推薦流程，畢竟都是通用的。之前項目，把svn很多行爲都做了封裝，我認爲缺點是svn使用者解決問題思路極其受限，完全依賴svn管理員；對svn使用者和管理員都不是好事。

svn內容太大，怎麼解？

svn內容太大，危害就是svn up、svn co、svn st的過程緩慢。
解決思路：

1. 非常穩定的設計（比如購買的IP），放在trunk目錄以外。
   例如：

   • project
     
     • trunk
     • tags
     • branches
     • stableVerilog
     • stableVerification

2. svn使用者第一次需要checkout整個目錄。

svn co svn://192.168.1.1/project project

1. svn使用者第二次以及之後的svn操作，比如svn update project/trunk。不需要再svn up project。解決svn內容太大導致svn up太慢的弊端。

svn的trunk經常不穩定，怎麼解？

項目更新，都在trunk分支上。但是不能保證每個人提交的內容，在trunk下都能穩定跑項目仿真。

思想，仍然是使用分支merge操作。

解決思路：

• svn tags的意義，更多是爲了提供一個正式版本，爲了FPGA仿真、R0signoff、R1signoff等。
• svn tags還有一個重要意義，比如每週打一次tag。以便trunk跑不通的時候，知道系統項目的哪個版本是最近穩定的。tag的名稱，可以是日期+版本號的形式。
  例如;

svn cp svn://192.168.1.1/project/trunk svn://192.168.1.1/project/tags/20170909_r211

• trunk版本，只有打tag的時候，纔是有意義的。trunk版本是大家共同維護的主幹分支，所有代碼都要及時提交至這個主幹分支裏；不必強求，每週打tag之前把自己代碼全部提交，不可能做到，只求自己代碼穩定時，就更新至trunk分支裏。
• svn使用者，仿真使用的不是trunk最新版，是在branches裏。同時，是基於最近穩定的tag版本。
  例如；

svn cp svn://192.168.1.1/project/tags/20170909_r211 svn://192.168.1.1/project/branches/qilei/20170909_r211

• svn merge命令是正規方法（之後再講這個操作流程）。有些人會陌生恐懼，其實多做幾次就理解消化成習慣了。當然，還有最原始的辦法可以推薦(這個最原始的方法，就是svn merge的思想，即diff and apply)。
  例如；當svn://192.168.1.1/project/branches/qilei/20170909_r211，該分支提交完成（重點，已提交），並順利通過仿真後，

#檢查自己的修改與trunk分支的代碼區別，參數--summarize，只會報告不同的代碼。
svn diff svn://192.168.1.1/project/branches/qilei/20170909_r211 svn://192.168.1.1/project/trunk --summarize

#更新trunk版本至最新版
svn up project/trunk


#把自己負責的代碼，拷貝到
svn cp project/branches/qilei/20170909_r211/xxx.v project/trunk/xxx.v

#最後，在project/trunk裏查看所有更改
svn diff xxx.v

#本着對自己對他人負責的態度，跑一遍project/trunk的仿真；然後提交至trunk分支，順便提交一個系統最近穩定的tag版本
svn ci xxx.v -m "commit my code to trunk"
svn cp svn://192.168.1.1/project/trunk svn://192.168.1.1/project/tags/20170909_r258

#至此，已經完成一個循環
svn cp svn://192.168.1.1/project/tags/20170909_r258 svn://192.168.1.1/project/branches/qilei/20170909_r258

svn merge

這部分是轉載的。
細節就以下幾點：
1. trunk到branches的merge；branches到trunk的merge。
2. merge時，一定要指明版本號。否則merge結果是最新版本號，即trunk和branches的代碼都是一樣的；這就沒有意義了。
3. svn衝突conflict的解決方法，選擇postpone方式，代碼確認後。svn resolve xxx.v --accept working，通知svn，已解決衝突；然後正常提交即可。
4. svn merge取消方法

svn diff
#可以看到當前merge後的改動信息，其中一個改動是增加了一個svn:mergeinfo屬性。

#svn merge操作出現問題，想取消這次merge。
svn propdel svn:mergeinfo

SVN分支和合並的簡單例子 儘管svn沒有作強制要求，但是一般svn版本庫目錄建議創建trunk、branches和tags三個目錄。 在實際操作時，trunk主幹版本要時刻保持乾淨，即隨時可以基於這個版本進行修改並將應用部署上線。branches是分支目錄，存放並行開發的項目代碼，因爲分支是主幹的廉價拷貝（相當只是提交了一次主幹版本，增加了一個版本號，並沒有取出版本庫作鏡像拷貝），所以你可以放心建立很多分支版本。不過Subversion不支持跨版本庫的拷貝，當使用svn copy時你只能在同一個版本庫內操作。tags目錄存放trunk某個的快照，比如說release-1.0即trunk處於1.0版本時的快照。

使用svn來作團隊的代碼管理，那麼分支和合並將是非常常用的操作。下面是一個簡單的示例。

1. 創建分支。這裏假設你要負責一個叫theme的項目，分支號1.7.2。

#這裏的localhost是svn服務器地址 svn copy -m "1.7.2 - theme" svn://localhost/www/trunk svn://localhost/www/branches/branch1.7.2-theme svn co svn://localhost/www/branches/branch1.7.2-theme


2. 從trunk中merge到分支。忙了一個星期終於開發完了，但是開發期間trunk版本有過改動，部署上線前你需要合併trunk的代碼。

#branch1.7.2-theme是分支目錄，注意不可以進到分支子目錄 cd branch1.7.2-theme
#前面的12972是開分支之前trunk的版本號，後面的12991是merge時trunk的版本號 svn merge -r 12972:12991 svn://localhost/www/trunk  

如果有衝突選擇p(postpone)，merge完了之後使用svn st|grep ^C查看衝突文件，然後比對修改衝突文件。解決衝突後再check in ，信息寫上執行的merge操作。 svn ci -m 'svn merge -r 12972:12991 svn://localhost/www/trunk'


3. 從分支merge到trunk。上線測試完畢，你很幸運，一切都如預期正常，這時就要將分支迴歸trunk，將trunk更新到最新。

#先從trunk checkout一份新鮮的代碼，然後cd到該版本目錄下 svn co svn://localhost/www/trunk  

cd trunk
#12973是分支開始的版本號，13006是分支結束的版本號 svn merge -r 12973:13006 svn://localhost/www/branches/branch1.7.2-theme  

如步驟2一樣解決衝突，解決衝突後再check in，信息寫上執行的merge操作。 svn ci -m "svn merge -r 12973:13006 svn://localhost/www/branches/branch1.7.2-theme"

衝突的處理方式

(p) postpone – mark the conflict to be resolved later //讓文件在更新完成之後保持衝突狀態。
(df) diff-full – show all changes made to merged file //使用標準區別格式顯示base修訂版本和衝突文件本身的區別。
(e) edit – change merged file in an editor //用你喜歡的編輯器打開衝突的文件，編輯器是環境變量EDITOR設置的。
(r) resolved – accept merged version of file //完成文件編輯之後，通知svn你已經解決了文件的衝突，它必須接受當前的內容—從本質上講就是你已經“解決了”衝突。
(mf) mine-full – accept my version of entire file (ignore their change//丟棄新從服務器接收的變更，並只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丟棄你對查看文件的本地修改，只使用從服務器新接收的變更。
(l) launch – launch external tool to resolve conflict//啓動一個外置程序來執行衝突解決，這需要一些預先的準備。

四、 疑問？

svn使用者未及時提交代碼至trunk分支，怎麼辦？

svn使用者在分支branches仿真穩定後，就應該提交至trunk；如果trunk仿真通過，branches就使用最新的環境。這個過程如上介紹，沒什麼複雜和時間花費。

提交代碼至trunk後，在trunk裏仿真不通過，怎麼辦？

找錯誤負責人，趕緊debug。
因爲提交的流程，可知trunk版本，是較爲穩定的。因爲每個人是仿真後提交的，所以錯誤都是容易馬上解決的。
即便一時難以解決，自己仍然可以使用原始branches分支，繼續維護代碼。

別人發現bug後。自己更新代碼，要在對方branches裏提交。儘量不在trunk裏直接更新，避免trunk不穩定。

svn使用者流程總是不清晰，怎麼辦？

總結常見FAQ，發佈在公共文檔裏。

svn備份

每週打tag的同時，做一個備份。備份利用覆蓋方式即可，不需要一週獨立一個備份；這樣可以節省硬盤空間。
svn備份一般採用三種方式 - CSDN博客
http://blog.csdn.net/beyondlpf/article/details/54138865

一個項目是多個svn倉庫，還是一個svn倉庫管理？

因爲版本號的原因，相關性較大的事項，作爲一個svn倉庫管理方便。比如設計與驗證。
相關性較小的事項，作爲另外獨立的svn倉庫管理方便。比如設計和驗證/RAM-io-stdcell-analog庫和綜合和時序分析和LEC。

因爲項目數據太大或者目錄層次太深，導致svn up和svn st等操作響應時間太長，怎麼辦？

1. 前期合理規劃；經常修改的代碼，放在一個目錄裏，該目錄下的文件數目儘量少，即可解決。
2. 使用固態硬盤，作爲本地working copy。經實驗，從一分鐘可以達到幾秒。
3. 如果出現誤操作，導致規劃不合理，可以利用徹底刪除svn服務器文件的方式，解決。