2011-03-17 69 views
3

什麼是當前(2011)只有一個位置的公司的推薦源代碼庫。什麼是小公司的現代源代碼庫?

分佈式存儲庫難以實現,因爲有兩個步驟來簽出和簽入。每個系統上都有一個完整的存儲庫副本。這是約。 50 GB與我們目前的系統。如果您想要結賬新​​的系統,這會消耗很多時間。沒有本地系統的備份。等等。

目前我們使用顛覆。但是顛覆在合併時存在很大的問題。

Eclipse插件將非常好,因爲這是我們使用的IDE。

地平線上是否有新星?

+0

你在使用什麼操作系統? Windows還是Linux還是混合?你的程序員的「標準」能力是什麼?他們可以在需要時使用命令行,還是在使用之前死亡? – xanatos 2011-03-17 07:51:57

+0

@ Horcrux7如此分佈式SCM無可爭議? – 2011-03-17 07:55:20

+0

[Git](http://git-scm.com/)與[github](http://www.github.com)!它快速,緊湊。另外,在每個目錄中都沒有數百萬個'* .base'文件或'.svn'隱藏文件夾。有Windows和* nix的客戶端。 – Zabba 2011-03-17 07:57:16

回答

1

作爲I just documented,Eclipse插件中的新星是... DVCS(Git通過EGit)。儘管它可能並不是你所追求的,但我仍然指出這是Eclipse上的當前「新星」,因爲所有的Eclipse項目現在都在Git倉庫中,並且Eclipse致力於爲Git工具提供良好的支持。

然而,它包含了許多的挑戰,因爲我把我的企業環境中這一新的VCS,這裏列出:
Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?

  • size limits for Git是一個重要:你不能只創建一個回購協議,並把一切(你的50GB)。
    您需要將源代碼分爲幾個回購站,並將二進制文件外部化到工件存儲庫,如Nexus(請參閱「什麼是is a repository」)。
  • 然後身份驗證問題需要解決,主要是通過一個包裝能夠識別誰推/拉:我使用gitolite
3

目前(2011年)有什麼建議,源代碼庫爲一家公司只有一個位置。

Git或Mercurial。

分佈式存儲庫困難,因爲有兩個步驟來簽出和簽入。

聽起來像我一樣,你看到DVCSes爲「Subversion但分佈式」。他們並非如此,想像他們會讓你錯過自己的優勢。

沒有兩個步驟來提交DVCSes。提交Git(stage,然後commmit)有兩個步驟,但這是一個Git功能,而不是DVCS功能。

我認爲(請糾正我,如果我錯了),你認爲這兩個步驟是提交(本地)和(到中央存儲庫)。如果您希望每個開發人員所做的每一項更改都能立即提供給其他人,那麼您只需要這樣做。

集中式系統(即SVN)簡直是不可避免的。使用DVCS,您可以使用提交作爲備份點而不是發佈。

不同的是,在SVN中,你不能提交不完整的代碼,因爲它會影響整個團隊(你這樣做,直到你修復它,團隊中沒有人會有可用的代碼)。在DVCS中,您可以根據需要(本地)提交(併合並),並且只有在有穩定的東西時才進行同步。一旦你習慣了它,「SVN方式」看起來不必要地收縮。我們與DVCS合作的方式如下:我們(8個開發人員左右)有一箇中央存儲庫,每個內部版本(測試團隊)之前每週同步一次。我們每個人都會在構建之前同步它們的源代碼(從服務器拉取更改,合併,拉取)。然後,我們中的一個會在服務器機器上構建一個。

很多時候,我們會有兩位同事在新功能的兩面工作,並且僅在我們自己之間同步測試代碼。當我們有穩定的東西時,我們會把它放在服務器上。與此同時,其他開發人員不必看到不完整或破損的代碼,並且中央代碼庫保持穩定,而我們仍然可以承諾並從源代碼控制中獲得全部好處。

在每個系統上都有一個存儲庫的完整副本。

這很好。這意味着通過創建本地存儲庫,您可以獲得100%的完全冗餘,並且可以有效消除服務器單一故障點。如果您的服務器硬盤崩潰,您只需將其中一位開發人員的本地存儲庫克隆到新的服務器硬盤。

這是約。 50 GB與我們目前的系統。

但是,您只能爲每個客戶端同步它們一次。初始同步後,所有後續的都是增量式的。

如果您想要結賬全新的系統,這會消耗很多時間。

您可能會感到驚訝。轉移之前Hg和Git都會壓縮數據(我不確定SVN是否會這樣做),並且它們也會壓縮存儲庫本身。考慮到這些系統存儲的是更改而不是文件(即更改增量,而不是完整文件),與使用SVN相比,使用DVCS的存儲庫可能更小。

不足之處(如果您考慮冗餘和備份問題,您可以閱讀「優勢」)是您在每個克隆過程的本地複製完整存儲庫。

沒有本地系統的備份。

沒有必要 - DVCS存儲庫的備份通常不是問題。每個本地系統都是中央存儲庫的完整副本(包含完整的歷史記錄),中央存儲庫是每個客戶端存儲庫的完整備份(每次推/拉同步)。

使用一箇中央存儲庫和一位開發人員,您可以獲得100 + 100%的冗餘。有兩個開發人員,100 + 200%的冗餘。

它並沒有比這更安全。

目前我們使用的是顛覆。但是顛覆在合併時存在很大的問題。

關於合併,顛覆是由設計中斷,因爲它SVN不存儲任何元數據來決定如何合併(如SVN跟蹤文件,而不是更改)。當SVN合併時,它會嘗試進行有根據的猜測,這些猜測都是微不足道的。對於非平凡的情況,您最終會嘗試手動解決複雜(針對人類)問題,因爲它應該是您的工具/計算機。

+0

感謝您的大量描述。但我在某些方面不贊同我們的工作。可能是因爲我們工作是錯的。單個開發人員不可能編寫穩定的代碼。只有許多開發人員的代碼總和纔會產生穩定的代碼。要在相同的功能上一起工作,他們必須非常頻繁地合併它的代碼。例如全部30-60分鐘。這就像配對編程併產生非常好的代碼。接下來的問題是,如果開發人員在簽入並且測試服務器場已檢查它之前代碼是否穩定,則開發人員無法100%知道它。 – Horcrux7 2011-03-20 15:28:01

+0

你的備份參數我不明白。你寫道你一週只能同步一次。但是,您的更改只能在本地存在。如果您的硬盤在同步之前失敗,那麼您一週的更改將丟失。同時在一個本地保存備份上多次克隆存儲庫。簡單的火可以摧毀所有的克隆。您需要額外的備份。 – Horcrux7 2011-03-20 15:33:16

+0

我不同意你的一些論點。只要設計良好的方法受到尊重(TDD,開發測試 - 錯誤修復週期等),單個開發人員就可以編寫穩定的代碼。我已經看到它完成了。我從來沒有與測試服務器場合作過,但我同意測試應該是開發的一個持續部分。儘管這可以在合併的代碼上完成(我們是這麼做的)。 – utnapistim 2011-03-30 07:45:16