定義存儲庫的邊界

Question

我會先設置場景...

我們使用Subversion，目前有一個相當大的主存儲庫。儘管如此，我期待着將其打破，並有可能在晚些時候轉移到Git。原因在於：a）Git不能做子文件夾結賬，所以有利於較小的回購，b）我們可以使用更多的分支（每個功能分支）。

我們有一個web應用程序，也是一個web自動化應用程序。

它們不直接依賴於代碼。但是自動化應用在設計方面依賴於網絡應用。如果在網絡應用程序中進行了更改，則可能會中斷自動化應用程序。

我想將它們拆分成單獨的回購，但提出了一個很好的觀點。將它們置於相同的回購下很方便，所以你知道在一定的修訂版本中它們都可以一起工作。

用兩個單獨的回購庫，用兩套版本號來說明這一點顯然是非常棘手的。另一個問題是我們有很多應用程序（不僅僅是依賴於對方的自動化，API等等）。

只是想看看人們的想法。如果你已經處理了這樣的問題？你認爲他們應該或不應該分裂等...你是否使用某種部署工具來跟蹤每個回購協同工作的各種修訂等...

Answer 1

首先，你創建一個克隆你的svn存儲庫，然後您可以將生成的git存儲庫與git filter-branch分開。

要再次依賴兩個項目，請使用子模塊。通過這種方式，一個存儲庫可以與固定版本一起使用（對於庫很有用，對於web應用程序很有用）

Answer 2

就工具而言，如果使用Hudson構建，它會跟蹤使用的一組存儲庫和修訂號在每一個構建你。如有必要，您可以從此標記。

如果你有一種工具可以這樣工作，那麼限制你所追蹤的版本號的數量並不重要。我把它分成這樣 - 1個數字可以手動跟蹤，> 1個需要工具支持。但他們不需要成爲複雜的工具。

我更喜歡單個存儲庫，但這只是個人偏好。它基於一個修訂號碼是明確的，有多個回購你需要回購和數量。然後，政策變更（例如，這個用於代碼，這個用於公司文檔，這個用於部署等）。

Git只是不這樣工作，所以你沒有選擇使用單個回購。這並非壞事，大多數系統（如Hudson，Redmine）都會很樂意支持這一點。

Answer 3

拆分它們可以讓它們獨立釋放它們自己的版本號，但正如你注意到的那樣，跟蹤依賴性可能會非常棘手。我們從一個基於Ant的構建轉移到maven，以幫助我們處理我們的依賴關係，儘管存在一些問題，但它總體上值得。 （我們有多個應用程序，以奇怪而美妙的方式依賴於彼此的apis。）我們遵循的基本模式是使用Apache Portable Runtime's version numbering，這是一個三位數系統，其版本使用標準MAJOR.MINOR.PATCH約定。至於分裂他們的過程，我建議先在Subversion中分裂它們;那麼如果/當你移動到git時，你可以簡單地將git svn指向版本庫的相關部分進行轉換。