需要很好的理由從Perforce轉移到git - 真正的好理由

我在一家在美國和歐洲都有開發團隊的公司工作。目前，每個工廠都使用Perforce，並計劃共同構建新系統。作爲一個分佈式團隊，我很熱衷於轉向git或Mercurial，但是m'colleagues很謹慎。他們喜歡Perforce，並且看不到移到DVCS的任何好處。需要很好的理由從Perforce轉移到git - 真正的好理由

得承認我努力想出說服的好理由。兩個設施之間的快速線路意味着我們可以使用中央Perforce回購，或者爲每個設施克隆一個。

出現的一個問題是，不會有一個主回購：開發人員永遠不會知道他剛剛簽出的代碼是否是最新的 - 假設其他人正在更新相同的文件？

是的我是git/Mercurial noob。任何人都可以幫我解決難以辯解的原因嗎？

謝謝！

來源

2012-07-06 Return_Of_The_Archons

爲什麼你想轉移到git，如果你不知道你爲什麼要轉移到git？ = O – Pete 2012-07-06 14:57:37

你有足夠的肌肉來傳達你的視覺嗎？也許這屬於職業生涯。（j/k）。關於master repo，你可以使用一臺集中式服務器，並稱之爲''master repo。 – prusswan 2012-07-06 16:16:40

我有'肌肉'，但我想帶着我的團隊。不僅僅是強迫它通過呃。 – 2012-07-06 18:13:13

你的問題似乎並不約爲git的/反覆無常這麼多，因爲集中式與分佈式VCS：

分佈式VCS - 利弊
- 源的多個副本;如果服務器出現故障，代碼可以從多個工作站
- 本地副本意味着更新往往較小和較弱的網絡密集
分佈式VCS - 利弊
- synchonizing變化;如果您有簽入和多個員工在同一模塊的工作率很高，你需要有一個推一個非常明確的協議/拉/合併
集中VCS - 利弊
- 一個地方的代碼 - 你知道哪個庫是或者應該是規範
集中VCS - 利弊
- 一個地方的代碼 - 服務器不可用意味着開發者無法分支/版本LO NG沒有問題

來源

2012-07-06 16:00:14 lonstar

「你的問題似乎並不是關於git/mercurial，而是集中式與分佈式VCS的 - 」是的！感謝您的回答！你的第三個子彈對我特別感興趣，那就是艱難的管理問題。 – 2012-07-06 16:24:14

然後我建議你做開始感染小的歷史悠久的傳統。每個IT組織都有助手應用程序 - 小型裝載程序，示例代碼等。爲非重要的東西啓動一個DVCS存儲庫，以「遠離」大孩子主要產品的方式。讓人們在沒有威脅到主要任務的情況下獲得DVCS的經驗，過了一段時間後，飛躍似乎不會那麼大（再加上你會有更多的經驗，並決定也許這不是一個好主意）。 – lonstar 2012-07-06 19:18:32

此外 - 這不一定是一個或兩個。有很多集中的DVCS存儲庫（例如GitHub）。如果您在中央服務器上創建裸露的回購站點並將其推入其中，則您有一個用於備份，構建等的中心位置，但仍享有分佈式優勢。 – lonstar 2012-07-06 19:22:26

如果您不知道任何切換原因，您爲什麼要切換？

雖然人們可以給你git的特性，他們喜歡perforce缺乏 - 「本地存儲庫意味着更快的歷史！」，「我不能沒有git bisect」，「perforce沒有藏匿，所以很難檢查離散單元！「......沒人能告訴你git比你的公司做得更好。

所以問問你自己：「我的部門需要的是什麼perforce缺乏？」和「沒有Perforce正在執行的某些限制，我們可以做得更好嗎？」。一旦你回答了這些問題，看看git是否可以提供幫助。在提出真實問題的最後，「難以與理由爭論」將在您手中，並適用於您的實際同事。

來源

2012-07-06 15:23:08

這是我提出問題的原因的一部分...... – 2012-07-06 16:21:54

也許我需要重新翻譯我的問題，例如：任何人都可以想到從集中式VCS移動到分佈式VCS的任何場景都是明智的嗎？這可能是我的'真正'問題。 – 2012-07-06 17:00:37

要回答這個問題，「誰能想到這裏從一個集中的VCS移動到分佈式之一將是明智的任何方案？」是的，我可以：

您的開發團隊非常鬆散耦合。他們有獨立的時間表，管理，標準等。他們如此獨立，以至於CVCS僅僅是官僚主義的繁文tape節。
他們所做的開發不受審計或合規標準的約束。沒有關於誰做什麼的核心記錄，這對公司不會造成問題。

來源

2012-07-06 18:38:24 user1054341

需要很好的理由從Perforce轉移到git - 真正的好理由

回答

相關問題