「最佳」svn轉換爲我的具體目的轉換工具

當談到從svn轉換爲hg似乎有一百萬頁致力於它（無論是在stackoverflow和網絡一般），但他們都似乎要有關於哪些工具可用的洗衣清單以及可能的建議（雖然它們各不相同，並且通常並不真正說明爲什麼建議這樣做），但沒有提供使得工具最適合我的要求的因素的真實信息。正如大部分信息來自2010年左右一樣，有時候會有筆記或其他頁面顯示「該工具已過時和/或維護不好」。隨着hg的迅速發展，2010年也可能成爲石器時代。「最佳」svn轉換爲我的具體目的轉換工具

我想從svn轉換爲hg主要是爲了簡化一些嚴重的合併。我很樂意將整個團隊轉換爲hg，但是由於種種原因，這還不會發生。所以可能會有一段時間我會使用hg，而其他團隊繼續使用svn。因此，對我來說，重要的是能夠往返，即將svn repo轉換爲hg，使用hg，然後將更改推回到svn。由於svn repo會不斷進行更改，因此能夠將hg存儲庫與svn repo同步也很重要。雖然當地的hg回購服務可以滿足我的大部分用途，但我還想在服務器上保留一箇中央服務器，這樣我就可以說服其他人嘗試。

據我所知，DVCS與hg和git更好地合併的主要原因並不在於它們是分佈式的，而是它們將歷史保存在更有利於合併的形式中。如果我將svn repo轉換爲hg，hg會以其首選形式獲得足夠的歷史記錄，以便它能夠更好地合併？什麼時候我同步？

我不關心轉換工具運行在哪個操作系統上，因爲我們將Windows 7用於筆記本電腦和服務器上的Linux（我有超級用戶可以訪問）。如果有什麼我可能更喜歡Linux，因爲這是svn回購和中央hg回購的地方。我也不關心最初轉換需要多長時間（雖然同步是另一回事），因爲我可以在星期五開始轉換並在星期一進入（我們的svn回購沒有那麼大）。

任何人都可以給我一些建議，關於哪些svn工具將符合我的具體要求？

來源

2015-08-16 NedLudd

是的，一些合併會更容易關於着名的「樹衝突」），其他一些令人頭疼的成本（與SVN上游相關）。 Pure Mercurial會更加順暢 –

純水銀（TortoiseHG在Win-盒）+ HGSubversion

只是克隆SVN回購本地的Mercurial回購
工作，致力於汞
hg pull將等同於svn up
hg push將發佈對SVN-repo的更改

一些注意事項（從hg help svn部分啞引號）：

當從Subversion轉換，hgsubversion不承認merge- 信息，並且不產生基於它合併。
Mercurial合併不能推送到Subversion。你必須衍合上SVN HEAD
多頭上樹枝也不能推的頂部工作（SVN歷史是線性的，違背了汞的DAG）
這是不可能與一個以上的互動每個Mercurial克隆Subversion版本庫。

的一些注意事項和觀察，不適合在評論以及

SVN不合並信息從水銀隱藏，這是目前的主線 - HGSubversion，這忽略此數據。但即使是不正確的公共父項（在SVN合併後的HG合併的情況下）也不能防止更改塊的整潔定義（至少從內存中「循環交叉分支合併」 - A-> B-> C-> D - > A - 在HG中沒有問題，與SVN相反）
在使用Branch Per Task工作流程的實際SVN項目中，我並行使用了SVN-WC和HG-WorkDir（將SVN回購克隆到本地Mercurial，主要是在合併/資源進入WC以承諾回購）。我更喜歡在不同地方分離Hg和SVN，但從理論上講它可能是常見的（WD + WC）目錄，相互忽略外部元數據

來源

2015-08-16 22:24:15

謝謝。「當從Subversion轉換時，hgsubversion不能識別合併信息，也不會根據它創建合併。」聽起來像svn基本上丟失了可能被hg捕獲的信息。在這種情況下，hg可能不會讓我的合併更容易，但我一定會嘗試。也許我可以儘快將團隊的其他成員推到hg。 – NedLudd

再次感謝。「它是當前的主線 - 忽略這些數據的HGSubversion」聽起來像是有一個開發版本不這樣做。你知道嗎？唯一能找到的是版本爲538bbb927609的版本，網址爲https://hgsubversion.googlecode.com/hg/。 – NedLudd

@NedLudd - 通過https://bitbucket.org/seanfarley/hgsubversion/（「......這項工作的最大特點是能夠從Subversion存儲庫導入合併...」）我發現這個fork https： //bitbucket.org/seanfarley/hgsubversion/官方擴展 –

「最佳」svn轉換爲我的具體目的轉換工具

回答

相關問題