從StarTeam遷移到分佈式源代碼管理

Question

我們目前正在爲我們的項目使用StarTeam，許可即將到期。我們正在考慮轉向Team Foundation Server或類似的方式，但是推動（主要來自我和另一個人）轉向某種形式的分佈式版本控制。其中一個問題是，我們的變更經理希望能夠通過更改請求進行跟蹤和發佈（如StarTeam中所述），我不相信這可以通過Mercurial或Git開箱即用輕鬆完成（請如我錯了請糾正我）。

這是一個擁有數千個Java文件和PL/SQL包的15歲以上的產品，由5-6個開發小組維護，總共有30-40個開發人員。對我而言，這似乎會使分佈式存儲庫成爲「早期提交，經常提交」思維模式的噩夢。每個團隊都將在同一個存儲庫中完全不同的子系統上工作這一事實使得它在我的腦海中變得更加棘手。

我們對任何改變目前的StarTeam過程是這樣的：

1. 鎖定的文件（S）你想工作，
2. 會讓你的整個變化，並把它從一個副本回顧了網絡上開車，
3. 入住（和解鎖）已更改的文件，希望有人沒有強行破鎖的，
4. 希望你的變化是從別人的變化構建不破其他文件

就我個人而言，我認爲「鎖定」文件的想法是荒謬的。團隊之間應該有足夠的溝通，這樣你就不需要了。

有沒有人在這裏有類似大小項目的分佈式存儲庫的經驗？您能否就版本控制和/或變更管理解決方案提出任何建議？主要要求是系統能夠管理客戶發起的變更請求，並強制開發人員將他們的簽入鏈接到一個。

謝謝。

Answer 1

Git和Mercurial都用於複雜程度遠遠超過您所提及的項目。因此，使用Git/Mercurial來解決項目團隊規模問題不應該成爲問題。

本質上，我們希望對版本控制服務器進行更多的控制。 Subversion因此受到歡迎。

如何根據使用DVCS（如Mercurial或Git）的變更集來維護版本很容易。

你可以有一個回購設置，只有在回顧後才能推送變更集。這應該可以減輕變更經理的要求。

DVCS確實帶來了優勢，您可以輕鬆創建實驗分支或克隆，如果它不起作用，就會拋出它們，並在您認爲它們已準備好用於黃金時段時進行更改。經常提交/提早提交是一種適用於DVCS的實踐，因爲您將更改推送到自己的回購站。一旦烘焙完成，您可以向上推動團隊內的可用性。

鎖定文件是一箇舊時代。它甚至沒有被Subversion等工具所使用。這實際上是妨礙工作的障礙。

Answer 2

Git不會提供您正在尋找的「變更管理」流程。這是商業版本控制系統喜歡做廣告以吸引企業閃亮物品的管理要求之一。這並不意味着你不能這樣做，它只是在git的目的之外。很像，身份驗證和訪問控制（您可以使用ssh和gitolite，但git本身不提供這些服務）。除非您使用常見的錯誤跟蹤工具，否則您可能需要自行開發此集成。

鎖定文件總是錯誤的。這就是「合併」的意義。

我目前正在與10個開發人員合作開發代碼大約200,000行代碼，並且git的工作非常好。我們的團隊比其他項目上的git還要大一個數量級。 Git的優勢在於合併，這就是它如何處理多個開發人員和大量提交。請記住，每一次推動都是git中的一個合併，無論它看起來與否。您的本地存儲庫可能有一個名爲master的分支，但與中央存儲庫中的master不同。爲了同步它們，你需要做一個合併，有時候這只是一個「快速合併」。

我們不打擾強制鏈接改變請求。當我考慮編寫一個接口來做到這一點時，我碰到的一個問題是如何讓愚蠢的跟蹤系統意識到每個分支都存在一個錯誤。一個簡單的鉤子是不夠的。

你應該轉移到git的開發過程改進。對我而言，它從根本上改變（改進）了我編寫代碼的方式。如果沒有所有來自昂貴的IBM工具的預先包裝的子彈，您將面臨一個挑戰，即要提供一個git更好地進行業務變更管理的案例。真正的問題是，一旦你擁抱git，你將永遠無法再與任何其他工具一起工作，無論他們出現多麼好的商業案例......

Answer 3

我們已經非常成功地使用git 。我們遵循這個過程。很容易跟蹤任何問題上取得進展：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

如果你看看評論，有跡象表明看着過程中的一些有影響力的人。這是一種非常棒的工作方式，希望寫作能夠爲您提供所需的彈藥。對於TFS具體的東西，看看這裏：

TFS branching, what are the advantages（誤導性標題）

Answer 4

我在評論中寫道，但我認爲這是重要的，以至於它值得一個完整的答案。

我作爲Mercurial顧問工作，當我與客戶交談時，他們經常要求「變更請求」和「變更管理」。當我告訴他們Mercurial有沒有這樣的概念，他們感到驚訝。像Git一樣，Mercurial是一個重點工具。它確實使用版本控制，並允許您定義頂層的工作流程。如果您願意，您可以根據更改請求來說明工作流程，但您不必這樣做。

處理變更請求的典型方法是將它們放入某種問題追蹤器中。可以使用Mercurial中的命名分支或使用Git中的提交消息中的註釋完成將變更集與CR鏈接。當推送到中央服務器時，問題會被掛鉤更新。

你提到應該處理那些不應該成爲發佈版本的變化。最簡單的方法是在知道變化穩定之前不合併到主線。您仍然需要在分支上運行測試，因此您需要一個可以逐個測試每個分支的測試設置。爲了測試分支之間的依賴關係，您暫時合併它們並對結果運行測試。您可以繼續在分支上工作，隨後的合併會很小。

最後，當您想承諾釋放分支時，將其合併到主線中。

Answer 5

以下是將StarTeam項目轉換爲GIT存儲庫的小型Web應用程序。

http://dl.dropbox.com/u/101447754/startgit.tar.gz

我發展，因爲在我的工作決定遷移，並給了可能性，如果沒有以前的研究工作，任何一組做出這樣的過程。

現在：

StartGIT ES UNA sencilla herramienta對trabajar CON Controladores德Versiones，蘇鰭ES PODER convertir未repositorio連接StarTeam執行GIT，對ELLO SE腦水腫USO德爾腳本 「svnimporter-1.2-ST」 obtenido恩「http://www.polarion.com/user/direct_register.php?dl=svnimporterst」：

特納instalado： - GIT - 混帳svn的 - java的 - Apache2的

Pasos： - Descomprim IR 「startgit.zip」 - Colocar LA carpeta descomprimida 「startgit」 恩報上級目錄 「/無功/網絡/」 - Abrir navegador網絡Ÿcolocar LA siguientedireccción的 「http：//本地主機/ startgit」

// -------------------------------------------------- -----------

StartGIT是一個簡單的工具，其目的是將一個Starteam存儲庫轉換爲GIT。

此腳本使用 「svnimporter-1.2-ST」 獲得 「http://www.polarion.com /用戶/ dl的direct_register.php = svnimporterst？」

已安裝： - GIT - GIT中-svn - java的 - Apache2的

步驟： - 在 「/無功/網絡/」 將解壓縮文件夾 「startgit」 - - 打開網頁瀏覽器，「HTTP解壓 「startgit.zip」 ：//localhost/startgit「

Answer 6

目前有一個StarTeam的git遠程助手，它也可以用來將StarTeam的歷史記錄導入到git存儲庫中，該git存儲庫可以作爲StarTeam的替代品。

的代碼是在https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features（它的git-ST的一個特性分支能夠做這種進口的一個分支的分支st_to_git_migration_features。）

看到：https://github.com/warrenfalk/git-st/blob/st_to_git_migration_features/README.migration.md關於如何完成它的說明。

我已經使用它來成功將StarTeam的歷史記錄導入git存儲庫。