管理第三方开源库更改的最佳实践？

Question

在最近的一个项目中,我不得不修改一个开源库来解决功能缺陷.我遵循SVN创建"供应商源"存储库的最佳实践,并在那里进行了更改.我还将补丁提交到该项目的邮件列表中.不幸的是,该项目只有几个维护者,他们提交更新的速度很慢.

在某些时候,我希望更新库,我希望我的项目将要使用升级的库.但现在我有一个潜在的问题......

我不知道我的补丁是否已经应用于第三方库的未来版本.我也不知道我的补丁是否仍然与升级组件的内部实现兼容.并且很有可能,其他人将在那时保持我的项目.

我是否应该以特殊方式命名库,以便我们做出特殊修改(例如,commons-lang-2.x-for-my-project.jar)？我应该只记录补丁并引用自述文件中的SVN位置和邮件列表项的链接吗？在升级方案中,我无法想到的任何选项似乎都是万无一失的.

这是什么最好的做法？

Answer 1

SVN“红皮书”的供应商分支章节很好地介绍了这一点。本章中的示例似乎与您的情况非常匹配：

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

...
现在你面临着一个有趣的情况。您的项目可以以某种脱节的方式容纳对第三方数据的自定义修改，例如使用补丁文件或文件和目录的成熟替代版本。但这些很快就会成为维护难题，需要某种机制来将自定义更改应用到第三方代码，并且需要在您跟踪的第三方代码的每个连续版本中重新生成这些更改。

解决这个问题的方法是使用供应商分支。供应商分支是您自己的版本控制系统中的目录树，其中包含第三方实体或供应商提供的信息。您决定吸收到项目中的供应商数据的每个版本称为供应商删除。
...