管理第三方開源庫變更的最佳做法？

Question

在最近的一個項目中，我不得不修改一個開源庫來解決功能缺陷。我遵循了SVN創建「供應商源代碼庫」的最佳實踐，並在那裏做了我的更改。我還將該補丁提交給該項目的郵件列表。不幸的是，該項目只有幾個維護人員，他們提交更新的速度很慢。

在某些時候，我期待庫更新，我期望我的項目將要使用升級的庫。但現在我有一個潛在的問題...

我不知道我的補丁是否會應用到這個未來版本的第三方庫。我也不知道我的補丁是否會與升級後的組件的內部實現兼容。很可能，其他人將在那個時候保持我的項目。

我應該用特殊的方式命名庫，所以很明顯我們做了特殊的修改（例如commons-lang-2.x-for-my-project.jar）？我應該只是記錄補丁並引用SVN位置和鏈接到README中的郵件列表項目？沒有我能想到的選擇在升級場景中似乎是傻瓜式的。

這是什麼最佳做法？

Answer 1

供應商分支機構 SVN的「紅皮書」一章涵蓋了這一點。本章中的例子似乎密切配合您的情況：

http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

...
現在你會面對一個有趣的情況。您的項目可以以一些脫節的方式存儲對第三方數據的自定義修改，例如使用修補程序文件或完整的替代版本的文件和目錄。但是這些很快就成爲維護頭痛，需要一些機制來將您的自定義更改應用於第三方代碼，並且需要使用您跟蹤的每個後續版本的第三方代碼重新生成這些更改。

此問題的解決方案是使用供應商分支機構。供應商分支是您自己的版本控制系統中的目錄樹，其中包含由第三方實體或供應商提供的信息。您決定吸收到您項目中的供應商數據的每個版本稱爲供應商下降。
...

Answer 2

除了伯特的答案，這是很好的，只要問題的源頭控制部分而言，我還建議你寫一些單元測試覆蓋更改。

不要誤解我的意思，我不是故意說你應該只寫一兩個單元測試，然後忘記它。爲了使迴歸測試/單元測試真正起作用，需要系統性地實施，並且需要成爲項目自動化建設過程的一部分。

很明顯，這也不容易，一旦你離開了，你不能保證你的替換者/你的同事繼續使用你的測試策略。這也是你必須記錄，細化，使其更容易做到的事情，並不斷教育你的同事和管理人員。