選取程式時所要考慮的決定性因素

在決定要使用哪個程式時,必須考慮一些重要的因素。

用戶端對伺服器與點對點

配送資料時常使用的模式有兩種。第一個模式是,所有的用戶端都以中央伺服器為準,將其檔案同步化。伺服器至少必須偶爾可以讓所有的用戶端存取。CVS 使用此模式。

另一種可能性就是,讓網路上所有主機都以點對點的方式將彼此間的資料同步化。rsync 實際作用於用戶端模式,但任何用戶端都可以當作伺服器使用。

可攜式

在許多其他的作業系統上也可以使用 CVS 以及 rsync,包含各種 Unix 與 Windows 系統。

互動式與自動化

在 CVS 中,資料同步化是由使用者以手動方式啟動。這讓使用者對於要同步化的資料進行良好的控制,並可輕鬆地處理衝突。然而,如果同步化間隔太長,就比較可能發生衝突。

衝突:發生與解決

即使有數個人員同時在某個大型的程式專案上一起工作,在 CVS 中發生衝突的機率還是相當地少。這是因為文件是在個別的行列上進行合併。當發生衝突時,只有一個用戶端會受到影響。CVS 中的衝突通常都可以輕易解決。

rsync 中則無衝突處理功能。使用者必須小心不要覆寫檔案,並手動解決所有可能的衝突。基於安全著想,可以另外使用 RCS 這一類的版本設定系統。

選取和新增檔案

在 CVS 中,必須分別使用 cvsadd 指令,明確地新增目錄與檔案。這讓使用者對於要同步化的檔案擁有更大的控制權。另一方面,新檔案時常會被忽略,特別是在處理大量的檔案而忽略了 cvs 以及 update 輸出中的問號時。

歷程

CVS 還有另一項功能,那就是可以重新建構舊的檔案版本。每個變更都可以插入簡短的編輯符號,而且之後可以根據其內容與符號輕易地追蹤檔案的發展。這對論文與程式文字而言,是一種很珍貴的助力。

資料量與硬碟需求

所有相關主機的硬碟都需要有足夠的可用空間來儲存所有分散式的資料。CVS 在伺服器上還需要額外的空間,供儲存庫資料庫使用。檔案歷程記錄也會儲存在伺服器上,因此需要更多的空間。當文字格式的檔案變更時,只需儲存修改過的那幾行。每當變更檔案時,二進位檔案就會需要與該檔案大小相同的額外空間。

GUI

有經驗的使用者通常會從指令行執行 CVS。然而,在 cervisia 之類的 Linux 系統中,以及 wincvs 之類的其他作業系統中都有圖形使用者介面。許多開發工具 (像是 kdevelop) 以及文字編輯器 (像是 Emacs) 都支援 CVS。使用這些前端程式的話,衝突的解決方案通常會更容易執行。

使用者親切性

rsync 較易於使用且適合新進人員。CVS 某種程度上較難操作。使用者必須瞭解儲存庫與本地資料之間的互動。對資料的變更應該先在本地與儲存庫合併。這是使用 cvsupdate 指令來執行。接著必須使用 cvscommit 指令將資料傳送回儲存庫。只要瞭解此程序,新進人員就可輕鬆使用 CVS。

防止攻擊的安全性

在傳輸期間,應該保護資料以防攔截和竄改。CVS 與 rsync 都可以透過 ssh (安全的外圍程式) 來使用,提供安全性以防護此類攻擊。應該避免透過 rsh (遠端外圍程式) 執行 CVS。同樣地不建議在不安全的網路中使用 pserver 機制存取 CVS。

針對資料遺失的防護

開發人員使用 CVS 來管理程式專案已經有很長的一段時間,而且極為穩定。因為開發的歷程記錄皆已儲存,所以 CVS 甚至提供保護,防止某些使用者錯誤發生,例如不小心刪除檔案。

表格 39.1. 檔案同步化工具的功能:-- = 很差,- = 差或無法使用,o = 中等,+ = 良好,++ = 優異,x = 可用

CVS

rsync

主/從

C-S

C-S

可攜式

Lin、Un*x、Win

Lin、Un*x、Win

互動

x

x

速度

o

+

衝突

++

o

檔案 Sel。

Sel./file, dir.

目錄

歷程

x

-

硬碟空間

--

o

GUI

o

-

困難度

o

+

攻擊

+ (ssh)

+(ssh)

資料損失

++

+