1. 首頁
  2. 問答
  3. 管理SVN標籤和中繼

管理SVN標籤和中繼

2009-11-19 41 views
1

我將我們所有的源代碼轉移到SVN倉庫中幾個星期，真正開始看到這種魔力。我現在有一個非常簡單的問題，它會對我的SVNing方法做很多說明。管理SVN標籤和中繼

我在一個客戶的網站上工作了3個星期，在ProjA的主幹上工作。在我離開之前，我在「ProjA/tags/release-09.11.17」（日期戳版本號）下創建了一個幹線分支，這樣我就可以準確構建緊急bug修復。

剛纔客戶打電話給我一個確認了一個簡單的數學錯誤，我修復了它。我不知道如何處理更新我們的回購協議，我看到有幾個選項：

1）提交修改到ProjA主幹，並刪除「ProjA /標籤/釋放，17年9月11日」

2）提交對ProjA和「ProjA/tags/release-09.11.17」的更改

3）提交對ProjA的更改，爲TODAY「ProjA/tags/release-09.11.19」創建一個新標籤並刪除舊標籤「ProjA /標籤/釋放，17年9月11日」。

任何這些都有我看到它的優點/缺點。在接下來的幾周內，ProjA將看到很多發展，客戶不會再看到，直到我再次回到現場。

想法和原因？謝謝！！

來源

2009-11-19 bufferz

回答

2

這是一個壞主意（至少從我所知的標記/分支）刪除標記。該標籤在以後的日期供您參考 - 將它想象爲一個及時的書籤。如果你想找到你放入該版本的代碼，標籤將永遠在你身邊。

如果您想根據該標籤開始開發的新分支，則始終可以使用svn cp來完成此操作。您可以在那裏提交您的更改，進行一些測試，然後將其作爲後續版本進行標記，這就是它 - 您無法更改已發佈的內容。之後，您可能需要將修補程序移回您的主幹。根據您在合併信息（通過svnmerge.py或核心svn樣式元數據）方面設置的內容，以及您在分支中實際需要做多少工作，這可能是微不足道的或者是痛苦的。

我的外賣建議是試圖避免實際承諾一個標籤（除了最初的創建）。

來源

2009-11-19 15:01:34 MikeSep

+0

「如果您想根據該標籤開始一個新的開發分支，那麼...」 「我的外賣建議是儘量避免實際提交標籤（而不是最初創建的標籤）」。 您是否認爲即使使用明顯的錯誤修復而不是發展變化，這種方法仍然可行？ – bufferz 2009-11-19 15:24:39

+0

這是一個公平的問題。誘惑很高，只需對標籤進行快速更改即可。這就是svn將分支和標籤簡單地作爲主幹副本（或其他方面）的簡單方法。在其他源代碼控制系統中，你不會真的想用這種方式使用標籤（在git中，你肯定會創建一個分支），所以我認爲這是一個糟糕的主意。 – MikeSep 2009-11-19 15:36:16

+0

我認爲你需要一個發佈分支，在發佈的過程中一路標記。發佈分支的末尾可能總會被標記，並且該標籤看起來是多餘的，直到您將新的高優先級修補程序添加到發佈分支的末尾。與此同時，您可以在幹線上進行更多的實驗性更改。 SvnBook中有一節簡要介紹了這種分支風格： http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.release – MikeSep 2009-11-19 15:38:20

1

如果你不希望任何的樹幹得到釋放我會改變ProjA /標籤/釋放，17年9月11日然後合併這些變化到主幹

來源

2009-11-19 14:54:32

1

我相信SVN福音是改變/ tags是爲了做你剛剛做的事情 - 標記代碼處於已知狀態的特定時刻。我認爲你想要做的是在/ branches/client中創建一個分支，然後你可以通過trunk來合併最新的分支。當你完成這些工作時，你也可以將一個已加蓋日期的版本複製到/標籤中，以此作爲記憶的輔助手段。

來源

2009-11-19 14:56:18 Matt

+0

「SVN福音書」正是我所期待的。我試圖避免未來「我希望我會以這種方式接近它」s：P – bufferz 2009-11-19 15:28:46

1

我建議您將更改提交到發佈分支並從發佈分支重新部署代碼。然後，您可以將分支更改合併到未來版本的主幹中。

使用該方法，您將保留髮布代碼的完整性，但也要確保修補程序進入未來版本。

來源

2009-11-19 14:56:27 jonstjohn

+0

看到我的評論在你上面發表，我的問題也適用於你的評論。 – bufferz 2009-11-19 15:28:00

1

我認爲您正在向後看，如果存在正在進行的重疊打包更改，首選的方法是在分支中進行這些編輯。錯誤修復和短期補丁將進入主幹。

在處理長期項目時，可以將錯誤修復合併到分支中，以緩解分支的最終合併回幹線。

因此，您的緊急修復將進入主幹，並被合併到分支/版本09.11.17。

來源

2009-11-19 15:04:23

+0

所以，如果我的理解正確，你建議我保持實際運行（在客戶端的網站）副本ProjA始終位於branches/clientA目錄中，即使它恰好與trunk相同？然後對該分支進行一些小改動並保持合併。一直保持標籤僅供參考，但從未實際編輯它們？ – bufferz 2009-11-19 15:27:05

1

如果您不希望將所有ProjA/tags/release-09.11.17和ProjA/[email protected]之間的變化是在釋放ProjA/tags/release-09.11.XX（與XX在於修正版的日期），你可以做的是：

  1. 副本ProjA/tags/release-09.11.17到ProjA/branches/fix_math_bug
  2. 修復該分支上的錯誤，運行測試（在這裏你也可以從主幹合併其他錯誤修正，如果你願意的話）
  3. 複製ProjA/branches/fix_math_bug到ProjA/tags/release-09.11.XX
  4. 刪除ProjA/branches/fix_math_bug

來源

2009-11-19 15:25:54 sbi

相關問題

 相關問題