我有一個爲多個操作系統(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下有我的計劃會是如此可怕的事情嗎?)請分享您的意見,尤其是您處理這些類型情況的經驗。
感謝
比我的公司做得更好:使用PDMWorks進行二進制版本更改控制。你知道,就在機械圖紙和文字文件旁邊。啊。 – Nate