版控遷移

資訊科技是不停前進的，因此「遷移」Migration 這個議題總是存在。對於開發人員來說，資產集中命脈所在的「版本控制系統」也逐漸從集中式走向分散式。本文首先嘗試探討不涉及具體應用系統的評估準則，後續將再輔以幾個案例以供佐證。

當我們準備將一個「舊版控」遷移至「新版控」時，可能要考慮幾個問題：

• 技術上可以遷移的有哪些？
• 技術上不可以遷移的又有哪些？
• 技術上可以遷移，但受限於其他因素準備放棄的有哪些？
• 未來對於新版控的新特性，有哪些規劃？
  

在展開之前，我們應該先對「技術」有所定義：由於每個人的技術不同，資源與成本的限制不同，事物的執行程度與完善與否總會有不一樣的結果，這樣會討論不完，因此我們只好將技術定義為「某個最廣泛使用的工具」，並假設此工具能百分之百地發揮。

「技術上可以遷移的」可能包括了以下的要素：

• 舊版控最近的樣貌
• 舊版控的歷史紀錄
• 舊版控的作者
• 舊版控的分支
• 舊版控的標籤
  

「技術上不可以遷移的」可能有：

• 認證（通常委託外部系統）
• 授權（通常因為完全不一樣的設計哲學，概念無法完美地在新舊系統間對應，例如舊系統也許可以針對目錄甚至於檔案設置讀、寫權限，但新系統僅能針對專案層級）
  

「技術上可以遷移，但可能放棄的」，依可能性大到小排列下來：

• 舊版控的分支與標籤
• 舊版控的歷史紀錄（太久以前的歷史並不具參考價值）
• 舊版控的作者（早已離職，分辨某甲與某乙並不具參考價值）
• 舊版控最近的樣貌中，因應用概念不同，並不適合遷移至新版控的檔案類型，如壓縮、影音等
  

「新版控的新特性」較常見的有：

• 分支模型
• 管理權限下放
• 與其他系統整合，尤其是問題追蹤，或軟體生命週期相關者
  

依循以上所提的概念，接下來作者將著重在「遷移」，嘗試以幾個不同的情境（Subversion / CVS / TFVC to Git）實務上的作法，未來幾篇應該都會採用相同的說明流程：

• 由一個可用的舊版控取得最近的樣貌（新版控的第一版候選）
• 安裝新舊版控間最廣泛使用的遷移工具
• 儘可能完整地遷移歷史紀錄、作者、分支、標籤並驗證
• 有計畫地篩選遷移的內容