版本控制：多版本地獄，文件同步

我有一套實用功能。說.5..10個文件。從技術上講，它們是靜態庫，跨平臺 - SConscript/SConstruct加上Visual Studio項目（不是解決方案）。

這些實用功能用於多個小型項目（15+，數量隨時間增加）。每個項目都有一些文件或整個庫的副本，而不是鏈接到一箇中心位置。有時項目使用一個文件，兩個文件，一些使用一切。通常，實用程序功能作爲每個文件和SConscript/SConstruct或Visual Studio項目的副本包含在內（取決於具體情況）。每個項目都有一個單獨的git存儲庫。有時候一個項目是從其他項目衍生出來的，有時候並不是。你以隨機順序處理它們中的每一個。沒有其他人（使事情變得更簡單）

問題出現在您修改這些實用功能文件的一個項目上時。
由於每個項目都有一個文件副本，因此會引入新版本，當您稍後嘗試（例如一週後）嘗試猜測哪個版本具有最完整的功能時（例如，您爲某個功能添加了功能），會導致混亂。 cpp在一個項目中，並在另一個項目中添加了另一個函數a.cpp，該項目創建了一個版本分支）

你會如何處理這種情況以避免「版本地獄」？我能想到的一種方式是使用符號鏈接/硬鏈接，但它並不完美 - 如果刪除一箇中央存儲，它將全部下地獄。硬鏈接在雙引導系統上不起作用（儘管符號鏈接會）。它看起來像我需要的就像高級的git倉庫，其中項目的代碼存儲在一個本地存儲庫，但與多個外部存儲庫同步。但我不知道該怎麼做，或者如果可以用git來做到這一點。

那麼，您怎麼看？

來源

2010-05-31 SigTerm

你說這些文件形成一個靜態庫。那麼爲什麼你必須在每個項目目錄中都有他們的副本？通常的做法是製作一個項目鏈接的靜態庫副本。 – 2010-05-31 13:13:11

我同意尼爾。將這些實用程序本身作爲一個庫來運行。如果您真的擔心沒有在鏈接庫中包含您不需要的實用程序，則最好保留單獨的make文件，以便爲需要它的每個項目構建庫。 – 2010-05-31 13:30:49

@Neil Butterwort：最初是一個「模板」項目（即需要複製的東西），它慢慢演變成更復雜的東西。我有點粗心，最後有多個版本。就這樣。 – SigTerm 2010-05-31 13:42:34

這是不完全清楚我想要什麼，但也許git的子模塊可以幫助：http://git-scm.com/docs/git-submodule

來源

2010-05-31 14:00:29

「我不清楚你想要什麼」。在多個外部git存儲庫中分離文件，而整個項目擁有自己的存儲庫。即我希望版本控制系統正確處理來自不同外部來源的文件。至少，理想情況下。如果不可能，我只想知道其他人如何管理這種情況。就這樣。 – SigTerm 2010-05-31 14:18:56

我們在一個單獨的項目中使用庫，並鏈接到已編譯的二進制文件。我們使用語義版本控制來保持一種理智的表面http://semver.org/（以及一些自動化基礎設施來分發內容） – 2010-05-31 14:27:27

正常的簡單方法是將庫作爲版本控制中的項目，如果存在修改，則僅編輯此項目。

然後，其他需要該庫的項目可以從庫項目中獲取所需的文件。

來源

2010-05-31 13:31:11 Nikko

在Subversion中，你可以使用外部（這不是我知道的GIT，但這些技巧可能仍然有幫助）。這是如何工作的：

斯普利特應用程序特定代碼（\ MYAPP）從通用代碼（\ COMMON）
取下應用程序的所有副本;他們只應該通過添加\ COMMON使用通用代碼
把在應用中常見的代碼作爲外部的\ MYAPP

您還可能有應用程序的版本。還要在通用代碼中引入版本。所以，你的應用程序將在資源庫中的以下文件夾：

\ MYAPP \ TRUNK
\ MYAPP \ V1
\ MYAPP \ V2

同樣，添加版本的共代碼，或者使用的版本號，這樣的：

\ COMMON \ TRUNK
\ COMMON \ V1
\ COMMON \ V2

或者使用日期，就像這樣：

\ COMMON \ TRUNK
\ COMMON \ 2010JAN01
\ COMMON \ 2010MAR28

\ MYAPP \ TRUNK的外部應該指向\ COMMON \ TRUNK，這很明顯。

嘗試將通用代碼的版本與應用程序的版本進行同步，因此每次修復應用程序版本時，通用代碼也是固定的，並且應用程序版本將指向相關的通用代碼外部。

E.g. \ MYAPP \ V1的外部可能指向\ COMMON \ 2010JAN01。

這種方法的優點是每個開發人員現在都可以擴展，改進，調試通用代碼。缺點是隨着通用代碼的增加，應用程序的編譯時間將會增加。

另一種方法（將庫放到版本系統中）的缺點是，通用代碼的管理（擴展，改進，調試）總是與應用程序的管理分開進行，這可能會阻止開發人員編寫通用通用程序代碼（每個人都開始寫自己的'通用'類的版本）。另一方面，如果你有一個明確而靈活的團隊負責共同代碼，那麼在最後一種選擇中，通用代碼將處於更好的控制之下。

來源

2010-05-31 13:55:51 Patrick

在配置（一般）而言，一個解決方案是有多箇中繼（分支）：

釋放
集成
發展

發佈
此主幹/分支包含已通過質量保證，並且可以發佈到客戶端軟件。發佈後，所有文件都被標記爲「只讀」。給出一個標籤來識別發佈號碼的文件。

定期或根據需求，測試專家將從集成主幹中獲取最新的（小費）版本，並提交至苛刻的質量測試。這是如何將集成版本升級爲發行版本。

集成
該行李箱包含了最新的工作代碼。它包含錯誤修復和新功能。這些文件應在每個錯誤修復或新功能之後進行標記。

錯誤通過質量測試或新功能已完全開發（並經過測試）後，代碼被移入集成分支。這裏的一個好主意是在集成開發人員的代碼之前用臨時標籤標記集成版本。

開發這些是由開發人員爲修復錯誤或開發新功能而設計的分支。這可以是移動到本地計算機上的所有文件的副本，也可以是需要修改的文件的副本（鏈接到所有其他文件的集成主幹）。

在中繼線之間移動時，代碼必須通過資格測試，並且必須有權移動到中繼線。例如，未經授權的新功能不應放入集成分支。

在你的情況下，該文件必須要麼籤回他們已被修改後或整個新的分支或主幹如果代碼是從以前的版本也不同（如添加新的集成後備箱特徵）。

我一直在研究GIT和SourceSafe試圖找出如何實現這個模式。架構很容易在更大的配置管理應用程序（如PVCS和ClearCase）中實現。看起來像GIT，重複的存儲庫是必要的（每個中繼的一個存儲庫）。 SourceSafe明確指出，每個版本只允許使用一個標籤，因此沒有更改的文件會丟失標籤信息。

來源

2010-05-31 16:51:08

版本控制：多版本地獄，文件同步

回答

相關問題