對樹結構進行全面更改后，將分支重新整合回主干

Question

在我開始之前的簡短說明：“准備階段”需要很多解釋，而且看來這更多是設計問題，而不是有關編程問題的問題。 問題實際上是關於SVN分支和合並的，因此請閱讀到最后。

場景：

我有一個帶有大量項目的大型Visual Studio解決方案。 我使用的是SVN，所以行李箱當然有我的生產線。 它由一個核心DLL程序集，一個“主” UI用戶客戶端和一些“插件”程序集組成，這些程序集通過在核心程序集上實現接口以在UI中提供功能以及通過利用一組服務來進行操作為所有插件提供通用功能的方法（例如持久性邏輯操作，集中式文件存儲體系結構的存儲操作等）

隨着時間的推移，我還構建了一些外部實用程序，這些實用程序必須復制插件中的許多業務邏輯。 我不會贅述，因為它將最終分散我的主要問題，例如，僅顯示服務器上的計划服務，該服務處理與特定插件數據有關的集中維護操作。

最初構建此應用程序時，我（愚蠢地）沒想到需要集中式服務層，因此我將核心程序集（無論好壞）進行了架構，如上所示，與應用程序的表示層緊密集成。 換句話說，將插件與用戶界面集成所需的UI表示邏輯以及插件執行通用插件邏輯操作所需的業務邏輯都是一個“核心”程序集的一部分。 因此，插件和集中式服務之間存在的許多“共享”邏輯導致代碼重復。

我決定采取主要的重構計划，將與演示文稿無關的通用邏輯放入一個“共享的”程序集中。 為此，我在主干上創建了一個分支。 我將通用代碼重組為一個“共享”程序集，並重新指向了客戶端應用程序（插件等）和外部服務應用程序中的所有內容，以利用共享程序集。 在許多情況下，我還必須重命名類，以適應將來的更廣泛的用途。 核心程序集仍然保留下來，只是為了代理插件和UI之間的表示層責任。

問題：

現在，我已經成功完成了重構，我想將分支重新集成到主干中。 即使在簡單的情況下，合並也是一件棘手的事情，但是我在這里面對的是很多樹上的沖突。 另外，除了駐留在一個全新的項目中之外，“共享”項目中的文件夾結構與“核心”項目中的文件夾結構有很大不同。 由於使用共享程序集的新機制，在許多情況下，類位於不同的位置。

我想維護每個類的版本歷史，從核心程序集中的舊類到共享程序集中的新類。 此外，我想保證合並成功。 這似乎很明顯，但是在測試整個場景的微型版本時，我始終無法以使分支功能完全完好無損的方式解決沖突。 此外，正如我之前所說，我已經重命名了某些類以適應其更一般的角色，這使得維護版本歷史非常棘手。

我將注意到，我正在使用AnkhSVN ，它在重命名文件以修復移動時在“正常”情況下會有所幫助，但在這些主要的樹沖突情況下似乎不起作用。 另外，我知道在不同版本的SVN之間合並的方式有所不同-我認為它是SVN 1.5之前的版本和SVN 1.5之后的版本。 我正在使用SVN 1.9.3。

我已經嘗試了好幾個星期了。 我一直在瀏覽SVN書 ， 像這樣的TortoiseSVN資源以及我可以從Google搜索中找到的任何東西，例如this ， this以及this －在很多很多其他東西中。 我覺得自己快要瘋了，我認為高級SVN（和Tortoise）無法用傳統的自學，從網上學習和讀書的方法來學習。 無論如何，我將不勝感激。

當您使用SVN創建功能分支並計划進行主要的樹更改和“移動”（即重命名），以便可以將這些更改與主干重新集成而又不丟失任何內容時，什么是正確的方法？

Answer 1

祝賀您踏上SVN中最“受歡迎”的耙子-“重構后合並地獄”！

痛苦的經歷為您的案件制定了（至少）兩個簡單的規則：

1. 切勿在SVN中執行重構
2. 如果您忽略規則1：以世界上一切神聖而美好的名義，請在分支重構期間不要碰到主干中的任何內容

如果你拒絕這些正義的盟約，你仍然有辦法得救

純SVN方式，又臟又長

合並所有子樹 ，這是樹沖突的來源，用手確定每個來源和目標，例如

svn merge NEW_PATH/NEW_NAME old_path/old_name

並通過完全合並完成這項血腥的工作

Tricky Mercurial-way（或Git-way，但我只是討厭Git）

前言 ：對於現代DVCS來說，這樣的合並根本不是問題，它們具有與SVN-repos的“橋梁”，因此-您可以委派這項工作，將其合並到所選的外部VCS並返回結果（有一些限制和警告）

我懶得談論所有DVCS，而只會解釋Mercurial（考慮到SVN背景，這將是痛苦最小的遷移）。

使用HGSubversion，Mercurial可以讀取（拉）和寫入（推）到Subversion存儲庫，但是-它不能將自己合並的結果推送到Subversion結果，因此：它將是多階段操作，在處理

簡要簡介

1. 安裝Mercurial（TortoiseHG）和HGSubversion擴展
2. 將整個SVN存儲庫克隆到Mercurial到某個臨時位置（不是當前的Subversion WC）
3. 合並分支到主線（SVN的主干成為default分支），解決（可能）上下文沖突（不是樹）
4. 檢測結果
5. 用Mercurial Working Directory的內容（分別注意.svn和.hg文件夾） 完全替換 Subversion工作副本（顯然是主干WC）。
6. 將WC提交到主干
7. 為了美觀和遵守所有規則，“ trunk”主干的mergeinfo數據（在步驟6中提交的我以后必須稱為mergeset，盡管在形式上不是真的）

高溫超導

PS-使用HGVS遷移到Mercurial似乎並不瘋狂