在subversion中創建一個「標籤」，指出下一個版本中應該包含哪些文件

Question

我一直在使用StarTeam進行版本控制，但是正在轉向Subversion。我一直在閱讀Subversion book，StarTeam似乎有一個主要特性，Subversion不會 - 標籤的概念。我知道Subversion有標籤，但是它們在StarTeam中意味着不同。在StarTeam中，我可以將一組文件標記爲「準備好構建」，然後只檢查這些文件並將其包含在特定版本中。然後，我可以創建一個凍結標籤，指出該版本中包含哪些文件（類似於Subversion標籤，除了它在那些特定版本上，不是目錄中的所有內容）。

有沒有辦法在Subversion中獲得這樣的功能？我知道你可以指定要修改哪個版本，但是在你有代碼並且即將發佈版本，發現錯誤或者某人決定特定更改的情況下會發生什麼情況不應包括在內。我知道你可以根據存儲庫和本地工作副本創建標籤，但是這涉及檢查不應包含的文件的特定修訂並創建標籤。隨着準備建立「標籤」，你不會把標籤放在你不想要的文件的頭版上。在Subversion中沒有出現任何自動的方式來指定某個版本的修訂。在分支中應該開發新功能的情況並不是這樣，但是如果修訂版本位於主幹中（或者在哪裏製作標籤），則更多，但不應包括在內。它可能不需要恢復 - 更改可能是適當的，但在未來的版本中，不是現在的版本。如果您沒有針對您需要的確切文件版本的特定修訂版，您似乎必須從存儲庫和您的工作副本手動混合和匹配。

在類似的情況下，如果Subversion中的文件不是發行版的一部分，並且不需要加標籤，會出現什麼情況。在StarTeam中，您不會將準備好的標籤附加到它們，但在Subversion中，它似乎是目錄中的所有內容。有沒有辦法從構建和標籤中排除這些文件？這是什麼svndumpfilter排除是爲了？

簡而言之，有沒有辦法只在標籤中包含某些文件的特定修訂版本，還是必須是版本庫中的特定修訂版本，或是存儲庫中的手動文件組合以及工作副本？

Answer 1

如果我正確理解您的問題，我相信可以在發佈之前的某個時刻通過分支來處理它（例如，在此版本中包含的所有主要功能已完成），然後仔細管理什麼合併到該「發佈」分支。 「主幹」對新東西免費。例如，如果確定了一個錯誤，那麼可以（a）固定在主幹上，然後決定是否也應該將它合併到發佈分支中;或（b）固定在分支上。這是我們遵循的過程，它運作得很好（但它也需要紀律和一定數量的正式流程）。

Answer 2

您在特定修訂版本上進行分支或標記。您可以修改分支，使其包含您想要在該分支中進行的特定更改或更新。一旦你分支，你可以改變你想要的任何數量的文件，並只爲那個分支進行更新。所以是的，你可以單獨將文件更新到較舊的版本，然後將它們提交到分支。

Answer 3

Subversion僅允許以原子方式標記源樹的整個修訂版。您正在尋找的功能需要您的源代碼管理系統和售票系統之間進行一些通信，該系統不僅保留要更改的內容，還需要爲每張票證更改文件。

例如，Trac解析提交日誌使用提交日誌中的語法＃將每個修訂與任意數量的票據關聯。

您需要一個模塊來維護與新版本相關聯的票據，然後計算哪些文件成爲增量發行包的一部分。

Answer 4

我認爲你最好的選擇是使用分支機構。根據您在新版本中的工作方式，您可以創建一個不用於主動開發的乾淨分支，也可以保持乾淨並使用分支進行主動開發。然後，當您的文件已完成並準備好進行下一次構建時，只會將這些文件更改合併到乾淨的分支中。

比方說，例如我們正在幹線，併發布版本1.0。然後，我們創建一個名爲maint-1.0的分支，沒有人接觸。我們繼續在後備箱中開發，當我們完成某些特性或功能時，我們將這些更改後的文件移動到maint-1.0分支中。請注意，您可能必須有兩份工作副本，並簡單地複製已更改的文件。做一個實際的合併將想要合併所有的改變，而不僅僅是特定的文件。

最終的結果是您的maint-1.0分支只在您的下一個版本中有您想要的更改。

Answer 5

我認爲其他的答案是非常多的，但只是爲了明確說明，這種情況在發佈分支中處理得很好。

這個想法是在開發的早期階段（或者從早期版本開始 - 假設您希望所有的東西都來自您分支的版本），並且使用正常的合併機制來促進版本的修改後備箱釋放。如果稍後決定修訂（或修訂集）的質量較差，則可以恢復這些合併。你的合併跟蹤（在烏龜中這個效果非常好）顯示了你所包含的內容以及仍然需要去做的事情，你可以跳過修訂版本，不按順序合併它們，並且通常會盡可能多地搞亂你的構建。很明顯，跳過和不按順序合併可能會爲您創造更多的工作，因爲您需要手動解決衝突 - 但它是一種在您需要時可用的工具。

與單個文件一起工作的優勢在於，根據需要提升/刪除整個功能集 - 您不必手動搜索不同文件，從而消除來自各處的更改。但是這確實需要你有明確的提交和評論 - 不要讓你的開發人員犯下「在星期五下午提交以確保一切安全」。