2011-08-03 259 views
8

我有一個爲多個操作系統(Linux和Windows,現在可能是OS X)和處理器構建的項目。對於這個項目,我有一些庫的依賴關係,這些依賴關係是外在的,但我有一些內部的依賴關係,它們以我的上下文中可能的每種操作系統處理器組合編譯(交叉編譯)的源代碼形式存在。使用git管理庫依賴關係

大部分的外部庫都沒有改變,很多時候,只是也許在當地的bug修正或更新的版本,我認爲它可能有利於項目實施的一些功能\ bug修正的情況。內部庫經常變化(1個月週期),由我公司的另一個團隊以二進制形式提供,儘管我也可以訪問源代碼,如果我需要修復一個錯誤,我可以做到這一點,並生成新的二進制文件爲我的使用,直到下一個發佈週期。設置我現在是以下(僅適用於文件系統):

-- dependencies 
    | 
    -- library_A_v1.0 
    | 
     --include 
    | 
     --lib 
    | 
    -- library_A_v1.2 
    | 
     --include 
    | 
     --lib 
    |  
    -- library_B 
    | 
     --include 
    | 
     --lib 
    | ... 

的圖書館保存在服務器上,我每次做一個更新時間我必須複製服務器上的任何新的二進制文件和頭文件。客戶端的同步使用文件同步實用程序完成。當然,庫的任何更新都需要向其他開發人員公佈,每個人都必須記住同步其「依賴關係」文件夾。

不用說,我不很喜歡這個方案。所以我正在考慮將我的庫放在版本控制(GIT)下。建立它們,將它們包裝在tgz \ zip中並將它們推入回購站。每個庫都有自己的git存儲庫,這樣我就可以很容易地標記\分支已經使用過的版本和測試驅動器的新版本。我可以輕鬆獲取,組合,更新每個庫的「流」數據。我想有以下幾點:

  • 擺脫保持圖書館的這個普通的文件系統的方式;現在完成單獨的文件夾保存和管理每個操作系統和每個版本,有時他們不同步導致一個爛攤子

  • 更多的控制它,以便能夠清楚地記錄哪些版本的庫我們使用了我們項目的哪個版本;就像我們可以從混帳(VCS)獲得與我們的源代碼

  • 能夠標記\分支我使用的依賴關係(每個和他們每個人)的版本;我有我的v2.0.0標籤/分支library_A通常我的項目,但我想測試驅動器的2.1.0版本,所以我只是建立它,把它推到不同的分支上的服務器上,然後調用我的這個特別的依賴指向新的分支

  • 構建腳本有更簡單的構建腳本 - 只是拉從服務器的來源,拉動依賴性和構建;這將允許同時使用不同版本的同一個庫的不同的處理器和操作系統組合(超過的時候我們需要的是)

我試圖找到一些替代直接基於Git的解決方案,但沒有成功 - 像git-annex哪種似乎過於複雜,我想要做什麼。

我現在面臨的事實是,似乎有強烈的意見反對把二進制文件放在git或任何VCS下(儘管從技術上講,我也有頭文件;我也可以推動文件夾結構,我直接描述爲git沒有tgz \ zip,但我仍然會擁有庫二進制文件),並且我的一些同事在共同的強烈意見的驅使下反對這個計劃。我完全理解git跟蹤內容,而不是文件,但在某種程度上,我會跟蹤內容,我相信它肯定會改進目前我們現在的方案。

什麼是更好的解決這種情況?你知道基於git(VCS)的東西的任何替代方案嗎?在git下有我的計劃會是如此可怕的事情嗎?)請分享您的意見,尤其是您處理這些類型情況的經驗。

感謝

+0

比我的公司做得更好:使用PDMWorks進行二進制版本更改控制。你知道,就在機械圖紙和文字文件旁邊。啊。 – Nate

回答

2

的替代,這將仍然follwo項目,是使用git-annex,這樣可以讓您跟蹤頭文件,同時保持二進制文件存儲在別處。
然後,可以將每個git回購作爲submodule添加到您的主項目中。

+0

我已經看過那個。它似乎不適合我的需求。我不確定如何將二進制文件的頭文件分開是一個好主意,因爲它們相互依賴 - 新版本的庫可能會添加到API中,並將頭文件的新版本帶入圖片中。我非常想不把它們分開。 – celavek

+0

@celavek:他們不會分開,邏輯上。他們將看起來是同一個Git回購的一部分。它只是存儲在別處的大型二進制內容本身。但從Git客戶的角度來看,他們都在同一個回購。 – VonC

+0

確實邏輯上他們會分開,但git-annex似乎不允許保留多個版本的庫。看起來我最終會使用像現在使用的基於相同文件夾的方法。我可以使用git-annex來分支和標記嗎?它似乎沒有從文檔那麼...我會看得更遠,但它感覺不能提供我真正想要的。 – celavek