在最近的一个项目中，我不得不修改一个开源库来解决功能缺陷。我遵循SVN创建“供应商源”存储库的最佳实践，并在那里进行了更改。我还将补丁提交到该项目的邮件列表中。不幸的是，该项目只有几个维护者，他们提交更新的速度很慢。
在某些时候，我希望更新库，我希望我的项目能够使用升级的库。但现在我有一个潜在的问题......
我不知道我的补丁是否已经应用于第三方库的未来版本。我也不知道我的补丁是否仍然与升级组件的内部实现兼容。并且很有可能，其他人将在那时保持我的项目。
我是否应该以特殊方式命名库，以便我们做出特殊修改（例如，commons-lang-2.x-for-my-project.jar）？我应该只记录补丁并引用自述文件中的SVN位置和邮件列表项的链接吗？在升级方案中，我无法想到的任何选项似乎都是万无一失的。
最佳做法是什么？
答案 0 :(得分：4)
SVN“红皮书”的供应商分支章节涵盖了这一点。本章中的示例似乎与您的情况密切相关：
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
...
现在你面临一个有趣的情况。您的项目可以以某种脱节的方式对第三方数据进行自定义修改，例如使用补丁文件或完整的文件和目录替代版本。但是这些很快就变成了维护问题，需要一些机制来将自定义更改应用于第三方代码，并且需要使用您跟踪的第三方代码的每个后续版本重新生成这些更改。此问题的解决方案是使用供应商分支。供应商分支是您自己的版本控制系统中的目录树，其中包含由第三方实体或供应商提供的信息。您决定吸收到项目中的每个版本的供应商数据称为供应商丢弃 ...
答案 1 :(得分：1)
除了Bert的答案，就问题的源代码控制部分而言，这是好的，我还建议你写一些涵盖你的变化的单元测试。
并且不要误解我的意思，我不是说你应该只写一两次单元测试然后忘掉它。要使回归测试/单元测试真正起作用，需要系统地实施，并且需要成为项目自动构建过程的一致部分。
显然，这也不容易，一旦你离开，你将不能保证你的替换/你的同事继续使用你的测试策略。因此，您必须记录，完善，使其更容易，并不断教育您的同事和管理人员。