demoshop

版本控管的必要性我不想在這裡多說，誰需要版本控管也不是我可以定義的，你只需要回想：

1. 你是否曾經有過打了一星期的報告因為某次的當機或中毒消失殆盡？
2. 程式開發的過程，業主反覆不定，一下要A一下要改B，當你已經修改到J版了，後來又和你說其實我覺得A版比較好？
3. 很重要的檔案不小心刪掉了？
4. 一個資料夾中留了一堆 企劃書V1、企劃書V2、企劃書V3 這種手動版本！
5. 這段字（這行程式）不是我寫的，到底是誰亂改我的東西！

    
如果你有以上症頭請考慮服用版本控管（往後文章簡稱版控）。再來的文章 demo 會介紹 Subversion 這一套版本控管工具，並且安裝與使用在 Windows 系統上。
 

（demo 曾經看過一個血淋淋的案例，有位研究生在下個月就要交論文了，但是這時候 NB 的硬碟掛了，備份也是上個月的事情，如果他有使用版控的習慣，根本一點都不用煩惱。）

在真的開始使用版控之前有一些基本概念是需要了解一下，以下的基本概念是屬於版控領域，並不限定於 Subversion 這套版控。

• 檔案庫（Repository）
  • 版控系統中需要有一個存放檔案的地方，這個地方稱為 Repository ，在 Repository 中存放了整個專案的所有版本，Repository 在不同的版控系統中有不同的儲存方式（如檔案、資料庫），Repository 是整個版控最重要的地方，所有使用者都需要從 Repository 取得或更新檔案，因此選擇一個穩定安全的機器來存放 Repository 是必須的，Subversion 可以支援使用http://、https://、file:///、svn://、svn+ssh:// 多種通訊協定。
• 工作區（WorkSpace）
  • 前文提到檔案庫中存放了所有的版本，但使用的實務上不可能需要全部的版本，因此我們會從檔案庫中取得需要的版本（通常是最新版）複製到自己的硬碟中，而這些存放於本機硬碟的檔案可稱為本機副本（Local copy）存放的地方稱為 Workspace 。
• 取得檔案（Checkout）
  • 開始一份工作的時候，工作區並不會有任何檔案，這時候就要選擇檔案庫中需要的專案來執行 Checkout ，版控軟體會從檔案庫中複製指定的版本（通常是選擇最新版）到你的工作區形成本機複本，這個本機複本與檔案庫的目錄結構是一樣的，用一個專案的角度來看只有第一次需要使用 Checkout 。
• 送交檔案（Commit）
  • 當你在工作複本中完成了你的工作（比如寫好一個功能），就需要將你的變動 Commit 到檔案庫中，在 Subversion 中沒有 Commit 之前的異動其他成員都不會知道。（往後文章會提出適當的 Commit 時機）
• 更新檔案（Update）
  • 在多人使用的環境下，整個檔案庫的檔案是會同時被多人修改的， Subversion 並不會即時抓取這些異動，必須等到您使用了 Update 功能，版控軟體才會將檔案庫和你的差異更新至你的本機複本中，在 Subversion 中預設會檢查使用者在送交檔案之前該檔案有沒有被異動，如果有異動會強迫使用者先執行 Update 。
• 分支（Branch）
  • 利用分支的功能可以有效隔離主線，當開發程式時想重構、測試寫法、開發新功能，這些可能不會那麼快處理完畢，而且可能會造成現有功能影響的動作都應該在分支下執行，執行完畢確認後再合併主線就可以大幅降低在開發時期對主線的影響，往後對於分支還會再提，現階段只需要記住分支內你隨便玩都不會干擾別人。
• 合併（Merge）
  • 當兩個使用者修改了同一份檔案，在 Subversion 中是採取「樂觀鎖定」的作法，也就是並不會限制一份檔案只有一個使用者才可以修改，而是在更新檔案的時候才去檢查衝突，假設 工程師 A 異動了檔案中的 1～3 行，而工程師 B 使用者異動了檔案中的 5～10行，工程師 A 先行送交檔案，接者工程師 B 要送交的時候系統會發現版本不同而要求先執行更新檔案，檔案更新的過程中會偵測到兩個版本的異動並無衝突而自動合併（Merge）異動。
• 衝突（Conflict）
  • 基於以上案例如果工程師  B 異動了 3～10 行，這時候因為同時異動到了第 3 行所以版控軟體無法自動合併，就會發出 Conflict 警告，需要使用者自行解決衝突。（請注意發生衝突後越早解決對系統影響越小）

因為衝突和合併的文字敘述感覺不是那麼容易理解，所以 demo 做了兩張圖來解釋，看圖就應該很清楚了