我們的大部分項目都使用了大量的公共代碼的SVN結賬用的外部。我們正在（最終）走向一個統一管理共享代碼的系統。我們將共享代碼視爲SVN中的單獨項目，然後將其作爲外部參考。然而，由於將庫從一種用法移植到另一種用法時不可避免地出現了一些不可避免的問題，因此我們傾向於將外部庫指向開發分支甚至是項目正在開發中的主幹。標記的開發分支
其結果是，我們已經標記爲發佈或內部里程碑文件時出錯。偶爾我們會標記一個項目，但不確保所有外部標記都是先標記的。我們如何解決這個問題？我正在尋找方法來減少發生錯誤的可能性，或者在製作這樣的草率標籤後進行恢復/修復。理想情況下，解決方案將是使SVN執行當前策略的一種方式，但我對任何遇到此類問題的經驗感興趣。
我會用兩種策略來解決這一問題
另外，你還可以想出一個預先提交的鉤子，檢查是否正在創建一個標記，以及是否所有的外部指向修正的修訂，如果不是這種情況，則拒絕提交。
這聽起來陳腐，但肯定是最好的事情是不是參考圖書館的發展分支。如果它是第三方庫，那麼你不會這麼做，並且使用自己的庫也不是一個好主意。
這看起來似乎是更多的工作，但如果你在引用庫遇到了一個bug，修復它，標記一個新的版本和參考，在您的項目新的標籤。
如果你真的必須引用庫的開發分支，你可以使用一個預先提交的鉤子腳本來決定你什麼時候做一個標記，並確保所有被引用的外部標記都是標記的版本：然後腳本可以使如果情況並非如此，則提交。每次你做一個承諾時都會感到非常激動。
確實，最好的辦法是不參考庫的開發分支。但是，這並不是我可以做出的實際改變，因爲我無法控制同事的行爲或保證不犯任何錯誤。 –
我們也希望強制凍結被複制到標籤的外部的政策，但還沒有完全實現它在服務器上呢。
這個想法是讓預提交鉤子使用svnlook命令和交易號來檢查副本中的任何「標籤/」目的地。如果遇到碰撞，必須檢查和搜索任何svn:externals。可能還有其他一些屬性來允許重寫政策。
顯而易見的問題是服務器上的負載以及該鉤子使用哪種語言。通常情況下SVN帶有更好的Python Ctypes綁定，不幸的是我上次檢查它不適用於Windows（既不可編譯，也不適用於此目標）。但是pysvn模塊可能就足夠了。除了這種語言，bash腳本可以工作，但會很混亂，不便攜。或純粹的C ...
雖然不像對待你的外部庫那樣對待你的內部庫嗎？如果您是Apache Ivy（或Maven），將庫發佈到中央存儲庫（版本號爲1.0或SNAPSHOT_20091005）並使用標準Ivy（或Maven）機制導入它們會很容易。
這樣，你可以刪除SVN外部的所有問題。當然，每個項目在創建發行版之前都需要使用標籤，但這是「發行版101」。
同意 - svn外部看起來像是比他們值得的更多的問題。在我看到他們使用的任何地方，如果沒有他們，我們會過得更好。 – Peter
我同意馬丁五世Löwis但想到我要指出的是，如果你只在你的svn硬編碼版本號：你是在自找麻煩的外部，如果你的外部也可以定義自己的svn：externals的！
在你的情況下，你不會想要去設置一個開發中間件的外部指定版本，因爲這將鎖定你的開發回購。你也不能忽略遞歸外部。最好的選擇是遞歸地標記所有的外部元素，這樣可以繼續開發，但是你爲每件事物形成你自己的標記/分支。
我有一個腳本，做這一點，但之前，我將它張貼:)
你有沒有在任何地方發佈這個腳本？ –
顛覆客戶端版本1.9有一個svn copy選擇--pin-externals看起來像它會做什麼在這裏想要將它清理乾淨一點。
感謝danielsh（Daniel Shahaf）在freenode IRC頻道#svn上爲此答案。
如果您有時間創建腳本來執行此操作，則選項2是更好的解決方案。這也是我用於項目標記的選項。使用選項1時，必須小心瞭解「外部」存儲庫的修訂版號（而不是您的根項目修訂版），如果從幾個不同的存儲庫中提取外部存儲庫，這會變得更加複雜。 – MOK9