目前我的公司正在使用cvs進行版本控制。我們有一箇舊的代碼分支，專門用於一個客戶（不要問）我們想合併到頭上。使用mercurial合併cvs分支
由於這個分支，我認爲善變的合併功能應該讓我的工作更容易一點頭之間的增量。我的理由是：
在這個階段，我期待善變提供比CVS更好merge support。
然後我會提交我的修改後備箱庫回CVS。
這種方法聽起來嗎？這種策略會導致一個不那麼痛苦的合併，因爲我認爲它會，或者是有什麼我失蹤？
Mercurial合併比CVS或Subversion更好的原因是因爲它追蹤兩個負責人/分支的最新共同祖先，因此您要確保您提供的信息準確無誤，否則您最終可能與更糟糕的合併。
如果你做這樣的事情：
hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0 # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge
然後爲兩國元首的共同祖先會發散點（抱歉，如果CVS的命令是錯誤的，它是一個仁慈的很長一段時間）。
問題在於知道POINT_OF_DIVERGENCE在CVS repo中的位置--CVS根本沒有跟蹤這一點，這就是爲什麼它自己的合併不使用它。
CVS最佳實踐始終認爲，只要你分支創建標誌着分支點的標記，但如果你不這樣做，那麼有你前面的一些棘手的狩獵。
沒有正確的最近的共同祖先Mercurial的合併將不會比CVS的更好。
是的，這應該可以工作，但是沿途可能會出現一些小問題（比如如何從CVS獲取源代碼到Mercurial中：使用hg convert或手動導入某個修訂版等）。
，如果你遇到一個問題，請創建一個新的問題。
內置的轉換擴展功能將不會只是很簡單的履歷，CVS做得很好。使用cvs2svn叫叉cvs2hg
個人而言，我不得不用'汞convert'擴展先走了，看它是否能制定出分歧發生的位置。我不知道它如何處理分支，但它會是我開始的地方。我從來沒有理由使用它（謝天謝地） – 2010-12-14 14:23:57
從我的經驗來看，它做了一個可怕的工作，猜測分支分歧，但那是很久以前的事了。如果你有分支點標籤（這是CVS的最佳實踐），那麼你最好明確地做。 – 2010-12-14 15:25:07