CVS不是分佈式版本控制系統,因此大多數實現不支持爲同一個存儲庫(即本地和遠程)部署多個服務器的概念。
這就是說,the CVSNT page at Wikipedia筆記:
In November 2008 the project released version 2.5.04 with support for
multi site repository replication or 'local' repository caches and
specific performance features for using large files use over a WAN.
CVSNT現在是一個商業產品,所以這可以提出一個挑戰,那些喜歡免費解決方案。 (正如任何好的封閉工具廠商會說,CVSNT讚賞說自由不是免費的,但是這是一個完全不同的問題。)
過渡CVS倉庫到CVSNT應該是微不足道以來CVSNT導出最小的併發症來自CVS。將複雜的CVS存儲庫遷移到DVCS並不一定沒有風險,尤其是如果CVS存儲庫持續插入修訂版,標籤,分支以及不支持的版本。由於這種性質的任何努力都可能需要整個組織的重大變革,所以如果有人要着手這樣的努力,考慮遷移到更普遍的DVCS的可能性似乎是謹慎的。
CVSNT並非CVS存儲庫複製解決方案的唯一商業供應商。例如,WANdisco頁面在維基百科說:
WANdisco provides replicated products for CVS, Apache Subversion, Git, Gerrit and Apache Hadoop.
注意,提到商用產品是決然不是他們的認可,也不是推薦。所分享的信息簡單地向讀者提供關於這種情況下的潛在選擇的一些知識。
存在其他潛在的解決方案路徑。關於「cvs存儲庫複製」主題的Web搜索產生的結果表明,某些CVS用戶使用類似Distributed Replicated Block Device的工具來分發對存儲庫所在文件存儲的訪問。此外,爲了更好或更糟,根據本地和遠程開發之間的併發水平,利用DVCS減少與遠程服務器的交互而不更改遠程服務器有時似乎是合理的,但要認識到下面的段落只是爲了向不想將遠程存儲庫由於某種原因遷移到另一個VCS的人員共享一個潛在的非顯而易見的解決方案。
該受訪者已經看到CVS結賬提交到DVCS的情況,以便其他開發人員可以利用DVCS以分佈式方式使用結帳工作。根據需要,基礎CVS簽出會定期與CVS服務器合併。當然,這增加了很大的複雜性,在本地開發人員需要訪問整個遠程存儲庫的情況下並不令人滿意,而且當本地和遠程開發人員並行使用分支機構時,這種情況很難實現。這個想法實際上只適用於遠程和本地開發鬆散耦合的情況(即存儲庫所在的遠程開發人員並不大量參與通過DVCS共享的代碼)。
參見: * How to run CVS in parallel with a (「centralized」) DVCS repository?
如果檢出需要7小時東西是可怕的錯誤。無論如何,如果你正在重新設計你的VCS工作流程,你應該考慮一個更現代的系統;像Git或Mercurial這樣的分佈式系統可能最適合您的用例。 – geoffspear
由於網絡問題需要7個小時,而不是因爲CVS問題。主要問題是我的項目已經15歲了,所以沒有機會使用其他版本控制軟件。 – user2798118
對於幾乎所有曾經使用過CVS的項目,這都不成問題;這已經是死氣沉沉的技術,幾乎每個人都在繼續前進,無論他們使用了多長時間。無論如何,我無法想象一個項目依賴中央倉庫,需要7個小時才能以任何方式結算成功,但是祝你好運。 – geoffspear