我在哪裏工作，我們有一個分支策略，基本上說，有一個最頂層main（稱之爲主，幹線，等等）這始終是穩定的，那麼一個項目組，然後一個項目，都與各自的main分支（攝從一個水平「向上」，更接近最頂端的主）。在項目層面，取決於涉及的工作的複雜性，可能會或可能不會完成特定功能的進一步分支。 （例如，不需要創建一個功能分支來修復幾個識別出的用戶界面文本錯別字。）通常，這很有效。我們還將控制數據庫層的源代碼作爲更大的源代碼樹的一部分，因此每個源根目錄下都有一個database結構。合併到子分支會導致刪除TFVC中的新子分支內容，如何解決？
在database子樹中，有一個patch目錄（在大多數分支中）有一個子目錄。該目錄是由vCurrent命名（例如，如果是的vCurrent 2.3 SP1 HF0，那麼這個補丁目錄將被命名爲2.3 SP1 HF0），包含的補丁，將來自升級的vCurrent數據庫模式（可能與數據轉換），以vFeature。 vFeature，這裏是有問題的分支進行生產的版本;這可能是vNext，vFuture或（在極端情況下）vNever如果發展不泛出來的某些原因。功能分支通常不具有目標發行版本，但它們可能具有目標發行日期。
因此，結構看起來像下面這樣：
main
database
patch
2.3 SP1 HF0 <--- indicating that "main" is at version 2.3 SP1 HF0
projectgroup1
main
database
patch
2.3 SP1 HF0
project1
main
database
patch
2.3 SP1 HF0
feature1
database
patch
2.3 SP1 HF0
現在，想象一下，一個關鍵的錯誤是在生產中發現並necessites立即修復，以推動main到2.3版本SP1 HF1的結果。或者管理層決定發佈一個版本（可能只有一個功能分支）以滿足市場需求，併爲我們提供2.4 SP0 HF0。管他呢。 「從」 2.3 SP1 HF0補丁並沒有在發佈應用可能會或可能不會仍然是適用的，但最重要的，必須根據具體情況逐案負責，每個分支的開發者來決定。 因此，新的當前版本號的新補丁目錄中創建，和舊的被刪除，因爲它不再是相關（它仍然可以從源頭控制勾選「顯示已刪除項目」，以及在發行drop分支，因此獲得特定版本的內容不是問題）。將這個變更集合併到各自的功能分支時，每個開發人員都需要查看其數據庫補丁集並根據需要進行更新，以符合來自上游的任何模式更改。
通常，這不是一個大問題，因爲修補程序結構的變化是在最上面的main（它又是穩定的）和向下滴流。
然而，如果第二（爲釋放）特性分支存在有自己的一套數據庫補丁，TFVC將涓滴上主要的2.3 SP1 HF0修補程序目錄的刪除操作看似不考慮事實該第二功能分支已將內容添加到已刪除的目錄並刪除這些新補丁以及patch\2.3 SP1 HF0。這顯然是不可取的。
在我看來，特性分支2中的情況是衝突：合併的一邊表示刪除，另一邊表示從未合併到合併源的新文件。在這種情況下，TFVC應該擱置一邊，將其作爲衝突呈現，並要求正在合併的程序員該做什麼。請注意，該目錄下甚至可能存在具有相同名稱但內容不同的文件（這是通過設計）。相反，它只是通過刪除目錄及其所有內容徹底將地毯從腳下拉出。
目前，我們處理這個主要是做對刪除「撤消掛起的更改」，然後移動新的補丁，並手動刪除舊目錄。這顯然感覺不理想，以及作爲極其危險的（所有它會採取是一個開發者在他們的全套未決合併來自上游的「小」變化前變化的不檢查，而他們有本地新鮮的數據庫補丁，你已經失去了工作和很多挫折）。
在TFS和TFVC的範圍內工作（所以請不要說「在DVCS模式下使用Git」或類似的東西），有沒有一種方法可以將這個問題實際上表現爲衝突？或者我們運氣不好，只能手動處理這種情況？這種情況並不經常發生，但由於分支機構數量衆多，顯然存在失誤的風險。
FAQ說工具討論是針對SO投票搬過來的 – DKnight 2011-12-29 15:26:44