與SVN相關的「幹線/分支」概念

我一直在嘗試SVN一段時間。爲了測試作爲SVN管理員和SVN用戶的不同方面，我有一個小測試項目。這裏先介紹一下。與SVN相關的「幹線/分支」概念

我有一個腳本：

<repos>/python/testScript/trunk/testScript.py

此腳本檢查一個環境變量$ LOCALSITE並列出結果。今天，我發現了一個簡單的腳本，如果該env。變量未設置。於是我立即分流到：

<repos>/python/testScript/branches/branch-00.01.xx/testScript.py

，也推一個標籤：「失敗的情況下，$ LOCALSITE沒有設置」

<repos>/python/testScript/tags/0.1.1/testScript.py

所以這第一個標籤仍然是繼承的錯誤就像幹線仍然遭受同樣的問題。

我推送標籤的原因是我％100確定此腳本將在正確設置$ LOCALSITE設置的環境中執行。所以它不會中斷。和往常一樣，人們可以繼續使用「tag-0.1.1」。

但是我仍然想解決這個問題。所以這裏是問題：

我已經修復並測試了「branch-00.01.xx/testScript.py」上的問題，所以現在我知道「branch-00.01.xx」正在工作，除非有更多的隱藏錯誤。那是正確的一步嗎？或者我應該修好後備箱？

現在我該怎麼辦？我應該將固定分支推向新標籤嗎？或者我應該修復後備箱並殺死分支「branch-00.01.xx」？

謝謝。

來源

2012-04-12 symbolix

分支模型假定您完成某個功能的工作後，將合併到主幹中。沒有必要標記它，因爲你不想將它暴露給外部世界。（事實上，你可以直接在主幹上做這個修復，但是我明白你正在探索這個過程）。

既然你剛剛開始，我建議你看看mercurial：它的語法很像svn，但它是下一代的「分佈式」版本控制。我不是故意說svn，這是一個很棒的系統，但這也是你想知道的。

來源

2012-04-12 18:20:24 alexis

是的，我想了一會兒，似乎這是我應該做的：修復樹幹。謝謝。是的，我試圖模擬一個svn體驗。 – symbolix 2012-04-12 21:33:09

分支也適用於錯誤修正（或新功能），如果在錯誤修復完成之前主幹可能會更改。當我自己工作時，我只將它們用於主要實驗，因爲在實驗完成之前我可能會對樹幹進行小修改。如果它失敗了，我也要隔離實驗，最後放到一邊（但可能想要稍後再回來並從中選擇）。 – alexis 2012-04-13 09:40:19

在某個層次上，選擇什麼並不重要，因爲爲方便起見，樹幹/分支只是邏輯概念（名稱），並沒有技術差異。

根據我的經驗，您通常會考慮使用最新最好的開發工具，而將分支留給已經推送給客戶的版本，可能需要稍後處理，但不要擔心正在進行中行李箱改變了事情。

來源

2012-04-12 17:49:09 TJD

不同的網站以不同的方式去解決這個問題。很多都是政策問題。

我見過，IMO的最佳方式：

1）Trunk是一種相對自由參加的所有，但也有可能是沒有什麼可以簽入樹幹而無需首先運行自動化測試的政策。這往往會減少在主幹上等待測試無關變化的人員。

2）分支仍在變化，但會逐漸減慢變化。簽入幹線的東西可能會被評估以檢入相關分支。過了一段時間，分支可能會被「凍結」，EG通過設置一個提交鉤子來拒絕所有不包含一些魔術餅乾的提交。如果有人想要足夠嚴格（通過查看提交歷史記錄），這很容易解決，但它可以消除凍結分支的意外登錄。

3）當一個給定的分支看起來相當穩定時，它會在打包Q/A之前被複制到一個標籤。這些標籤一旦創建就永遠不會改變，作爲一個參考點 - 儘管理論上SVN將它們視爲同等可變 - 但差異再次是一個政策問題。

所有這些的惱人的部分是SVN外部引用。如果你沒有，分支和標籤很容易 - 只需svn copy，你就完成了。如果你有它們，你最終會寫一個腳本來調整外部引用作爲分支/標記過程的一部分。但是有時候外部引用是非常有用的。我一直在嘗試在分支期間「內部化」所有外部引用 - IOW將所有外部引用作爲新創建分支的一部分進行復制，以保持分支和標記簡單。然後開發人員需要在有重要問題的情況下將問題檢查到更多的地方，但至少在我個人的項目中，它似乎更多的是幫助而不是阻礙。

來源

2012-04-12 17:59:56 user1277476

與SVN相關的「幹線/分支」概念

回答

相關問題