Subversion - svn：externals應該從哪裏來？

Question

我即將在這裏建立一個規則，所有svn：externals引用應該來自其他項目的標記之一，永遠不會來自它的主幹或任何分支。這是一個合理的規則還是你看到這種方法的問題/問題？我正在努力實現一個穩定的開發環境，我想知道這個規則是否會使開發變得更慢或更困難。

Answer 1

您的擔心是，具有「svn：externals」的項目可以在沒有任何提交到該項目的情況下更改。這是一個問題，因爲很難發現重大變化或回滾到一個好的版本。

所以，要求svn：外部引用穩定是一個很好的規則。只允許引用標籤是實現這一點的一種方式。另一種方法是使用-r語法將外部固定爲固定版本。例如from the subversion book：

第三方/皮-r148 http://svn.example.com/skinproj

這也將保護您免受在標籤的變化，一個不好的做法，這是更常見的比我喜歡。

這就是說，在穩定性和持續集成之間仍存在一個的折衷。無論如何，您通常需要外部依賴關係中的更改和錯誤修復。在這種情況下，您希望儘可能快地通過您的CI服務器通知相關項的某些更改會破壞您的項目，以便可以儘快修復此問題。大多數持續集成服務器都支持檢查外部數據。

因爲這個原因，我認爲可以將外部設備保持在跟蹤你的依賴關係（如果你有一個CI服務器）的trunk HEAD的主幹中。只需在標記和創建穩定的維護分支時將外部固定到固定版本即可。

Answer 2

我認爲這取決於您的軟件開發實踐的成熟程度。你有變更管理流程嗎？自動構建和報告？等最安全的做法是鏈接到項目的標記構建（即lib，dll's，jar's等）。

如果外部項目包含頻繁修復錯誤的每週發佈版，它可能既有幫助也有障礙。我發現如果沒有一個好的配置管理策略，鏈接到標籤就很容易錯過關鍵更新。而且，當你開始「升級」依賴關係時，可能會有很多小的變化加起來進行大量的工作。

對於相對穩定的項目，這是一個好主意。唯一的問題是並非所有的IDE都明確指出源目錄是外部引用。在這種情況下，開發人員很容易簽入對該標籤的更改。據我所知，Subversion尚未實現「只讀」，儘管我一直在使用舊版本。

Answer 3

而實際上允許外部的決定？確保您正確地使用它。簡單地從原始地點簽出並或者在多個地方簽入依賴關係通常會更好。過去我被外部參考文獻燒燬。如果你要分支他們成爲一個真正的問題，除非你「凍結」外部。

但是要回答你的問題，有一個特定的位置放置和引用所有外部設備是很有意義的。這意味着您可以控制該位置的內容，並且人們知道，當他們放置某些東西時，它將被用作外部，因此被很多項目所依賴。

Answer 4

這取決於你認爲樹幹的穩定程度。

1. 如果你的箱子總是準備好發佈，那麼你真的不希望你的外部指向箱子。
2. 如果您的發佈分支僅通過在trunk中進行修訂合併來更改，那麼您確實不希望外部指向trunk。
3. 如果出於任何原因，您希望在主幹中修改「我現在正在使用此外部版本」，從而控制對項目代碼的所有更改，那麼您不希望外部指向中繼。

但是，開發人員將其外部工作副本切換到主幹是很好的做法。在開發分支中指向主幹也很好。在項目第一次穩定發佈之前指向主幹可能沒有問題。

我個人的看法是非常小心地對待主幹，因爲它對我有特殊的意義 - 這是項目的完整歷史。根據定義，任何獲得釋放的東西都必須經過樹幹。如果您可以在沒有修改記錄的情況下更改主幹（這實際上是發生在如果指向外部幹線時發生的情況），那麼當您釋放該修訂時以及將該修訂合併到項目中時，您將失去控制權。

當你從樹幹分支時記住改變你對特定修訂的所有引用可能是一個試驗。哈德森可以通過其標籤支持讓事情更加明顯，但其他方面都無所幫助。

指向中繼線也會導致「untouchable library」問題。

當談到CI時，沒有理由不能對所有組件以及最終的集成項目進行CI。通過選擇何時合併到最新的庫中，您可以選擇何時進行集成工作。

但是，如果有一些機制說「您的項目使用的是過時的庫，最新的版本是X」，那就太好了。目前這是不可能的。另外，如果你有嵌套的外部元素，通過5層引用推動基本庫的變化，直到它到達主項目是一個痛苦。