多個SVN存儲庫或單個公司存儲庫

我們是否應該爲所有公司（包含許多開發項目）或每個項目的存儲庫擁有單個存儲庫？任何有關經驗/最佳實踐的想法？多個SVN存儲庫或單個公司存儲庫

2009-11-19 philbird

以我的經驗，你可以合理地去任何一種方式。 – 2010-04-14 15:17:37

在我們的組織中，我們有_many_不相關的項目，主要是.NET。我們正在考慮在解決方案級別使用存儲庫。這樣，相關的項目將在相同的回購和分享版本號，但不是無關的項目。我認爲應該把相關事情放在一起。如果你所有的項目都是相關的，那麼一個回購是有意義的。如果不是，那麼它不再有意義。 – 2013-04-10 14:41:26

就個人而言，我肯定會更喜歡每個項目的單獨存儲庫。有幾個原因：

版本號。每個項目存儲庫將具有單獨的修訂順序。
粒度。使用每個項目的存儲庫，您不能對具有相同版本號的不同項目進行提交。我認爲這更有利，而有人會說這是一個缺陷。
存儲庫大小。你的項目有多大？它有源代碼控制下的二進制文件嗎？我敢打賭它有。因此，大小很重要 - 二進制文件的每個修訂都會增加存儲庫的大小。最終它變得笨拙並且很難支持。應該支持二進制文件存儲的細粒度策略，並提供額外的管理。至於我，我仍然無法找到如何從存儲庫中徹底刪除二進制文件（由一些愚蠢的用戶提交）及其內容歷史記錄。使用每個項目的存儲庫會更容易。
內部存儲庫組織。我更喜歡細粒度，非常有組織，自包含，結構化的存儲庫。有一個diagram說明存儲庫維護過程的一般（理想）方法。我認爲你會同意在一次回購中使用'所有項目'是不可能的。例如，我的倉庫的初始結構（每個項目庫應該）是：
```
/project 
    /trunk 
    /tags 
     /builds 
      /PA 
      /A 
      /B 
     /releases 
      /AR 
      /BR 
      /RC 
      /ST 
    /branches 
     /experimental 
     /maintenance 
      /versions 
      /platforms 
     /releases 
```
回購管理。 '每個項目的存儲庫'在用戶訪問配置中具有更多的可能性。但它更復雜。但也有幫助功能：you can configure repositories to use the same config file
回收支持。我更喜歡單獨備份存儲庫。有人說，在這種情況下，不可能將信息從一個回購合併到另一個回購。你爲什麼需要這個？如果需要這種合併，則表明源控制的初始方法是錯誤的。項目的演變假定後續項目分爲子模塊，而不是其他方式。我知道有辦法做到這一點。
svn：externals。 '每個項目的存儲庫'方法鼓勵svn：外部使用。當通過軟鏈接建立項目和子模塊之間的依賴關係時，這是一種健康的情況，其中svn：externals是。

結論。如果您想簡化源代碼控制，請使用一個存儲庫。如果你想使軟件配置管理RIGHT：
1. 使用方法
2. 介紹軟件配置管理的獨立角色和分配團隊成員給它
3. 聘請了優秀管理員「每個項目庫」，誰可以應付所有的顛覆技巧:)

PS。順便說一下，儘管我一直都在使用SVN，而且我喜歡它，但是「每個項目的存儲庫」方法就是爲什麼我從存儲庫組織的角度看到DCVS系統更具吸引力的原因。在DCVS中，缺省情況下是項目。甚至毫無疑問「單一對多重」是可能的，這只是無稽之談。

來源

2009-11-19 09:37:38 altern

你多久看一次版本號？如果你需要保留一個特定的提交，那麼創建一個標籤就更容易了。 – Nick 2009-11-25 14:38:31

@Nick。當您不需要查看應用程序的其他部分中的更改時，如何合併單個模塊的修訂版本？對於大型應用程序，這將是一塌糊塗。我認爲，即使您有小回購，修訂號碼的一致性也會更好。儘管如此，修訂號並不是推動每個項目採用不同存儲庫的唯一原因。 – altern 2009-12-09 11:49:01

如果你有項目之間的耦合，那麼我會傾向於上面的原子性參數的單個存儲庫。這使得修訂版，標籤，分支機構和版本之間可以進行追溯。給定一個修訂版本號，您可以複製您知道可以一起工作的產品的全部來源。 – 2011-04-19 10:00:32

如果您使用的是Subversion，您可以在同一個域下擁有多個存儲庫，並且每個存在多個項目。

所以它會看起來像這樣

Project1: svn://svn.company.com/project1 
Project2: svn://svn.company.com/project2

PROJECT1可能解決前端代碼和包含子項目如管理員/和web/ Project2的是後端，幷包含各種工具和監控應用

如果你使用類似Git的東西，每個存儲庫應該是一個單獨的項目。

來源

2009-11-19 07:33:42 Verhogen

你可以，但你不能解釋爲什麼這是一個好主意。 – Avi 2009-11-19 08:17:14

我同意Avi。 – Eonil 2010-07-06 00:55:37

我會有一個項目的存儲庫，只是爲了每個項目的修訂號。您可以設置SVN以便使用Apache和DAV SVN（使用SVNParentPath指令）從一個訪問點訪問所有項目。

來源

2009-11-19 07:35:55

+1爲修訂編號。好點子。 – phidah 2009-11-19 07:41:10

版本號並不是什麼大不了的，Avi提到的東西確實是。 – 2010-01-03 19:21:15

由於所有分支也使用修訂號，因此修訂號參數爲紅色鯡魚。沒有分支的項目將在主幹中有順序的修訂號。 – 2012-07-17 13:51:37

我發現，具有在單一的Subversion版本庫艾滋病：

透明度：它是更容易跟蹤到底是怎麼回事，並找到代碼甚至你可能不直接參與項目在
維護：沒有必要建立資料庫每次你想創建一個新項目的時候，你可以刪除整個項目，而不必擔心失去從Subversion的記錄。
維護：只需要備份一個存儲庫。

編輯： 其他原因：

全球版本編號 - 具有版本編號是全球性的，它是：
1. 更容易溝通（例如，在代碼審查請求，只需指定修訂版 id，而無需指定哪個項目）。
2. 更容易保證原子性當項目彼此依賴。
3. 更容易看到承諾到不同項目的順序。

來源

2009-11-19 07:37:59 Avi

好點，雖然我同意修訂編號reko_t。 – phidah 2009-11-19 07:41:52

我不同意修訂編號 - 我已將理由添加到我的答案中。 – Avi 2009-11-19 08:16:27

透明度可以被看作是一種優勢還是一種缺點。我想到客戶需要保密的項目。 – mouviciel 2009-11-19 08:28:04

我強烈建議不要使用每個項目的存儲庫。在一個Subversion版本庫中，您可以移動和複製數據，並保留其歷史記錄。如果您決定將一段以後端工具開始的代碼合併到前端，並且這些代碼位於不同的存儲庫中，那麼這不是一個顛覆者會知道的操作。這就好像你從什麼地方向前端添加了一些東西。這也意味着如果您需要臨時維護兩個版本的相關代碼，則無法進行合併。

您會注意到，svn book中的所有示例都假定所有內容都位於一個存儲庫中。

還有一個單獨的問題：是使用/ trunk/project1，/ trunk/project2，/ branches/project1-r1還是使用/ project1/trunk，/ project1/branches/r1，/ project2/trunk。一般來說，第二個更容易跟蹤。

不把所有內容放在一個存儲庫中的最好的原因是訪問控制很難做到比在存儲庫級別上更細粒度。可能的，是的，但並不那麼容易。我們目前有兩個主要倉庫：爲所有的軟件開發

SVN /代碼，需要JIRA票提交
SVN/OPS任何配置，建立腳本，第三方焦油，不管，沒有JIRA需要

來源

2009-11-19 07:42:22

但是我強烈建議不要使用存儲庫*所有項目* – altern 2009-11-19 09:40:11

這個決定並不總是那麼明顯。在我的公司，我們爲不同的客戶開發完全獨立的項目，在這種情況下，每個項目都有一個單獨的存儲庫是非常合理的。 – 2009-11-20 23:58:38

該決定也可能基於項目的複雜性。如果你開始了大量的工作，將會與其他大部分工作分開，並且將有一個大型的開發團隊來開展工作，那麼給它一個單獨的回購可能是有意義的。

對於一次處理大量小型項目的團隊來說，單個存儲庫提供了一種簡單的機制來管理一個地方的所有內容（備份，搜索等）。中央倉庫也使倉庫本身看起來更加「具體」，因爲一旦項目完成或放棄它不會被丟棄。

來源

2009-11-19 07:46:52 kdmurray

這取決於您的應用程序/項目在組織中的相互依賴程度，以及代碼庫的規模有多大。這可以歸結爲您如何在組織中定義「項目」。共享代碼庫，共享組件，共享團隊，共享發佈週期都可能影響您的存儲庫需要如何構建。爲了簡單起見，我將一個項目定義爲具有獨立的代碼庫，發佈時間表和/或屬於一個工具/應用程序。如果是這種情況，我更喜歡每個項目有一個存儲庫。這樣，每個項目就有更多的自由來定義和實施政策/訪問限制。

如果隨着時間的推移，我有一個資源庫膨脹..我可能還需要擔心工作區檢出時間等，特別是如果項目的代碼都混合在一起。如果應用程序/工具/項目完成/擱置/廢棄/遷移，如果在項目級別存在分離，則可以對管理方面進行更多控制。

如果每個項目有一個存儲庫，則基於其獨特需求構建項目存儲庫也會更容易。每個項目可能都有特定需求，這可能會影響每個項目所遵循的配置管理策略（分支，標記，命名約定，CI等）。這並不是說你不能在單個存儲庫中以文件夾的方式完成所有這些。您可以。它只是讓事情變得更簡單，有更清晰的分離 - 就這些。

您可能需要考慮所有這些因素，以便根據您的特定設置評估最終可能產生的管理費用。

這就是說，如果項目規模都很小，並且相互依賴，需要交叉引用，交叉跟蹤，彼此間的移動等，那麼每個存儲庫最好使用單個回購和一個文件夾。

來源

2009-11-19 08:12:03

非常好，有見地的答案，到目前爲止，但我只想補充我的兩分錢：

我認爲這取決於你的項目的大小。我們已經嘗試了兩種方法，但最終以一個大型存儲庫解決。

缺點：

分支可能是困難的，因爲許多文件夾和文件可以參與
存儲庫可以成爲巨大的
你必須檢查出整個倉庫（或至少特定分支）來構建您的解決方案
對項目架構的控制略少（見專業版）

優點：

所有項目都共享同一存儲庫歷史
分支是整個倉庫
少得多管理（個人開發者可以在沒有系統管理員的幫助下創建新的項目）
存儲庫提交的更好的概述和監視選項

恕我直言（和關於我們的特定項目）專業人士超重的缺點。

來源

2009-11-19 10:03:06

這一切都取決於您擁有多少個項目，組織的規模，項目的相關程度等。如果你是一個擁有幾十個項目的大型團隊的一員，那麼每個項目的資源庫管理將會非常不便。

根據您的組織所執行的工作類型，另一個選項是每個客戶端有一個存儲庫。在我工作的地方，我們目前有四個存儲庫 - 一個用於我們完全內部的項目，一個用於我們銷售的軟件，另外兩個完全針對特定客戶，我們只爲他們生產定製軟件。這是一個「兩全其美」解決方案的嘗試 - 我們沒有一個包含所有內容的大型存儲庫，並且數十億的版本號（我顯然誇大了！），但是我們也沒有幾十個小的存儲庫每個項目都有一個項目。

來源

2009-11-19 10:03:57 Chris

對於我的組織，我中途去了，爲不同的編碼「區域」創建了幾個存儲庫。我事先知道每個存儲庫都會包含相互獨立的項目。

來源

2009-11-19 10:16:44 UncleZeiv

我所做的都在這兩種情況下有時我真希望我選擇了另一種方法...

我上一個版本庫結算是一個很好的解決方案。請注意，如果我在一家較大的公司，我會重新考慮。

來源

2010-04-15 15:39:29 Tim

我在一家公司工作，爲許多客戶提供嚴格的規則。目前我們有大約130位開發人員。我們有一個針對每個客戶需求定製的核心項目。我們有一個巨大的svn倉庫。如果我們必須檢查整個分支，那將是一件痛苦的事情，但我們的策略是將項目從共同分支中移出，並且僅將工作留給開關命令。 :)這樣一切都可以保存在一個存儲庫中。如果需要在outsorcing工作的一部分，或出售整個項目的情況下

我唯一關心的是一個倉庫多個倉庫的分裂，直到我發現這一點： http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories

所以我覺得SVN開關簡化了長時間結帳的痛苦（一個只會轉出所需的項目），但我們可以有一個存儲庫。但是，如果仍然需要，可以提取一組組件來分離存儲庫。

來源

2013-09-21 19:11:09 kottalovag

多個SVN存儲庫或單個公司存儲庫

回答

相關問題