如果我們從TFS轉移到Fogbugz窯，我們可能會遇到什麼問題？TFS vs FogBugz窯
目前我們正在使用TFS進行源代碼控制，我們正在考慮遷移到窯的選項。
我們是基於公司的，因爲我們使用Visual Studio .NET，SQL服務器，TFS，Windows服務器等全部微軟開發工具..
似乎對此舉的原因是：
有沒有人已經這樣做？當我們使用Visual Studio和Kiln時，有人知道問題嗎？
我不能完全回答你的問題，因爲我不使用（並且從未使用過）TFS。然而，我的僱主使用StarTeam，這對於源代碼控制來說是非常典型的。
對於我來說，從傳統的SCC檢出/檢入方法轉移到分佈式模型是第一個心理障礙。爲了克服這個障礙，我發現http://hginit.com/的教程很有幫助。至於使用窯與VS，我使用窯客戶端（本質上是TortoiseHg）和plugin for VS 2010。我可以從Windows資源管理器和Visual Studio中提交，拉出，推送等。除了學習mercurial以及分佈式版本控制如何工作以外，我沒有任何問題。
就其他問題而言，我能想到的唯一方法是更新任何構建服務器或持續集成服務器以從相應的存儲庫中提取內容。
TFS中存在Codereview（只需下載免費擴展），TFS中的合併非常好，TFS，方法論，集成和價格報告都更好。 以我謙虛的觀點。但兩者都是優秀的產品，如果你工作或需要分佈式sc或混合團隊（linux等），TFS也有解決方案，但價格並不便宜
從TFS 2008起，有可能陷入一場毫無根據的合併。現在這不是什麼好事。甚至沒有基礎的合併仍然不保留合併的分支歷史記錄（與Mercurial或Git相比）。在TFS 2010中它變得更好了嗎？ – Helgi 2011-03-30 23:41:39
不，它沒有。而且我也沒有太多的信心。 TFS團隊似乎認爲毫無根據的合併是一項功能，而不是一個錯誤，因爲完全困擾我的原因。 – jammycakes 2011-04-07 09:29:26
Mercurial中的分支比較好，但是這有一個價格：會有更多的分支機構，開發人員會犯一個錯誤並在錯誤的分支中執行某些操作會容易得多。靈活性可能會導致混淆。
但最重要的是你的過渡計劃。如果你在TFS中有很長的提交記錄，你可能想保留它。不幸的是，似乎沒有直接的轉換工具來幫助在需要時將TFS轉換爲Hg。我嘗試使用tfs2svn與hg convert，但tfs2svn卡住了複雜的重命名，我不得不寫一個愚蠢的直接轉換實用程序。
去年秋天，我們從Sourcegear的Vault（帶Bugzilla）切換到Kiln（帶FogBugz）。我們所有的開發人員都喜歡將代碼審查的提交與規範/要求的案例（bug /票據）緊密整合。
掌握中央知識庫的組織需要一些試驗和錯誤。窯（和代理商Mercurial）非常靈活，您可以輕鬆構建一個既簡單又過於複雜的組織結構。這可以通過您可以輕鬆分支和合並來顯着緩解。我們的目標是構建一個系統，該系統只允許將經過審查的代碼放入暫存存儲庫，然後將其部署到QA中進行發佈。花了大約6周（主要是試驗和錯誤）來完成我們的存儲庫組織，以簡化這一過程。
在Vault中（與從哲學角度看顛覆相當），您可以輕鬆地提交一個可能花費數小時的時間倒退的更改，在Kiln中進行更改並將其丟棄是微不足道的。雖然我不能說TFS，但編譯在Vault中發佈卻是一場噩夢。以90分鐘的生產力和垃圾。在Kiln中，編寫一些Perl腳本來自動構建/發佈是很簡單的，如果不是幾分鐘的手動審查，現在幾乎可以實現即時發佈。
最大的挑戰（正如Helgi所建議的）是管理分支機構。一些開發人員發現這非常容易，其他人則爲此而苦惱。
從Vault到Kiln都沒有轉換路徑，所以我們爲歸檔目的維護Vault服務器實例，並使用Kiln重新開始。
6個月，它改變了我們的生活（爲了更好）。
確定之前一定要看看Visual Studio 2010。這些領域有許多改進。 – 2011-01-19 21:58:58