svn - 管理对 3rd 方开源库的更改的最佳实践？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

6年前关闭。




Improve this question




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

在某个时候，我希望库会得到更新，并且我希望我的项目想要使用升级后的库。但现在我有一个潜在的问题......

我不知道我的补丁是否会应用于这个 future 版本的 3rd 方库。我也不知道我的补丁是否仍然与升级组件的内部实现兼容。到那时，很可能会有其他人维护我的项目。

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

这方面的最佳做法是什么？

Answer 1

SVN“红皮书”的供应商分支章节很好地涵盖了这一点。本章中的示例似乎与您的情况非常吻合:
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html

...
Now you face an interesting situation. Your project could house its custom modifications to the third-party data in some disjointed fashion, such as using patch files or full-fledged alternative versions of files and directories. But these quickly become maintenance headaches, requiring some mechanism by which to apply your custom changes to the third-party code and necessitating regeneration of those changes with each successive version of the third-party code that you track.

The solution to this problem is to use vendor branches. A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor's data that you decide to absorb into your project is called a vendor drop.
...