什麼是管理源代碼管理系統中程序所有權的有效方法？

Question

使用SVN或Git的想法發生在我身上，使用目錄結構作爲元數據佔位符。每個團隊都會在他們的代碼的共享存儲庫中擁有一個目錄。儘管這個想法似乎越糟糕，我越想它。對我來說，這似乎是一個壞主意的原因是，團隊不是靜態實體。團隊可以消失，分裂，重新組合，甚至可以獲得新的名字。我知道我正在使用一個唯一的標識符，可能是一個外部數據庫。我甚至可能面臨每個團隊存儲庫來適當地管理訪問權限。在擁有200個或更多團隊的情況下，我最好維護一個外部數據庫的所有權，還是可以從中學習一些工具和實踐？

Answer 1

這是我最好的嘗試，指出你在正確的方向。一般來說：

按照常規方式根據系統組件組織源代碼。確保每個組件都具有獨立配置的訪問控制（例如，在git中，這意味着每個組件都有獨立的存儲庫，正如Makis所說的）。

現在管理訪問權通常與LDAP結合使用。配置您的工具以通常的方式利用您組織的LDAP目錄。 （對於git來說，這通常是使用系統上的現有帳戶完成的，而這些帳戶可能會或可能不會被LDAP支持）。

以通常的方式使用您的版本控制系統內置的訪問控制機制，以允許每個團隊根據需要讀取或寫入每個組件。如果這種權限矩陣變得過於繁瑣以至於無法手動管理，則可以構建自定義機制以在更高級別上對其進行控制和/或自動執行大規模更新。

如果您沒有組件體系結構，集中用戶帳戶或VCS的訪問控制，請放棄此問題，直到您修復更重要的問題。

Answer 2

下面是我看到它完成的方式。沿相關技術行對齊目錄結構。這可能是基於團隊的。使用數據庫或其他東西將二進制文件（或源文件）映射到團隊成員。然後當事情四處移動時，你所要做的就是更新數據庫。

如果您將根做得很寬泛，那麼您的重組時間要比縮小時要晚。

Answer 3

讀你的問題，我有一個想法，能對您有用（或者不是，它只是一個閃光的想法已經出現在我的腦海中突然;-)：

1. 與Linux的「 devtodo'工具，您可以在每個目錄中爲元數據創建一個文件。 （對於devtodo，該文件被稱爲'.todo'）
2. 該元數據文件可能是nosql數據庫文件，與團隊成員在那一刻。
3. 該元數據文件可能在控制版本中。
4. 該元數據文件可以與其他文件（即所有團隊成員）連接（作爲sql連接操作）。
5. 可以定義一組腳本或shell別名來編寫更頻繁使用的nosql命令行。

在幾行中：關係數據庫文件在你的git或svn與你的元數據;並沒有數據庫服務器。

Answer 4

要存儲的元數據將保存有關與資源一起工作的文件和團隊成員的信息。假設你的資源庫中有資源處理的成熟語義，比如簽入註釋等，一種策略可能是識別你正在查看的元數據，並使用一些索引工具/ API來索引相同的元數據。從存儲庫元數據中可以獲得可以檢索和索引的大量信息。如果您需要更好的控制，您可以使用自定義的預先提交掛鉤來強制團隊成員在簽入時放置所需的信息。您將擁有的元數據存儲庫可以很好地控制查詢/搜索用戶和資源。索引可以通過腳本每天/每週執行。

Answer 5

Git沒有很好的訪問權限。爲了開始處理它，你需要使用gitosis，然後在git鉤子中寫入一些代碼。關於這個我有一個question。

然後，如您所說，您需要一個數據庫來處理有關哪個用戶可以訪問哪個存儲庫的信息。即你需要將這些東西分成不同的倉庫，因爲你無法保護git中的單個文件或目錄。我前一段時間寫了一個簡短的blog note。超級項目在未來可能會有所幫助，但是這個概念仍在建設之中，並沒有很好的定義。

對於像Rational ClearCase這樣的發燒友（和昂貴的）SCM工具，您有更好的工具。您可以創建組件並定義每個組件的用戶權限。不幸的是，即使這些工具需要手動大量更新，如果事情變化很大。但是，如果用戶權利是你所需要的，那麼編寫你自己的工具而不是購買這些怪物中的一個會更加划算。

Answer 6

給每個團隊自己的存儲庫。

Answer 7

行，所以，如果我理解你的問題正確，那麼你必須
1.多個程序
2.多支球隊的源代碼
3.工作需要跟蹤其團隊在其工作代碼

您沒有指定每次只能在一個程序上工作還是該程序 可以由多個團隊協作工作。

我不是一個GIT或SVN用戶，我的主要經驗是Perforce公司，但我會盡力和大綱應該針對任何大型企業級SCM系統

1. 有一個主線工作的一些最佳做法代碼分支 - 這將是您的'乾淨'區域。
2. 爲每個團隊創建一個沙箱分支
3. 使用明確的命名約定

每隊的沙盒將有完全訪問權限只，但不是沙箱中其他任何球隊的沙盒。

在倉庫佈局方面

所以再有這樣的事情

• 代碼
  • 主線
    • 程序1
    • PROGR AM2
  • 隊
    • teamA
      • 程序1
    • teamB
      • 程序2

每個團隊將隨後分支的代碼，他們希望在工作到他們的隊伍沙箱和可自由簽入任何的東西，他們喜歡。如果他們把他們自己的分支陷入泥潭，那麼他們的問題就是他們自己去解決問題，並運行他們認爲合適的方法。

一旦一個團隊很高興他們有自己的代碼的好下一次迭代那麼領隊只 有權促進和整合的變化高達主線

什麼像樣的SCM會告訴你整合歷史記錄，以便對於晉升到主線的每一個變化，你都會知道哪個團隊整合了什麼時間。

如果一支球隊解散，然後，如果你想
如果一支球隊名稱的變化，然後創建一個新的SANbox分公司辦理了新的團隊，然後從老東家沙箱的變化整合到新的沙箱

你可以放棄這個分支

在perforce上，你可以做一些時髦的東西，如反向集成，這非常好，因爲你可以將主線拉入分支，進行任何合併，然後集成回主線。只要代碼沒有其他變化，那麼集成就成爲直接複製。這樣做的好處是可以將「破損」主線向下推入沙箱，並保持主線清潔

無論如何，這是我的一些想法。SCM管理是整個區域本身，我敢肯定，很多人在那裏都會有一些更好的解決方案，但上述方法很適合我

在這個複雜的領域:)
Software Life Cycle Modelling
High-level best practices in SCM
一些有用的鏈接 SCM intro - repositories
SCM intro - branches

Answer 8

如果它是一個獨立的項目，只要給它一個自己的倉庫。