我在SO和其他地方看到很多关于“维护”的问题 VCS中的公共库“。也就是说，项目foo和bar都依赖于 libbaz，提问者想知道他们应该如何导入源代码 将libbaz插入到每个项目的VCS中。
我的问题是：WTF？如果libbaz是一个库，那么foo不需要它 源代码。有些库设计合理 以这种方式使用（例如gnulib），但大部分都是foo和bar 应该只是链接到图书馆。
我想我的想法是：如果你将库的源码剪切并粘贴到 你自己的源代码树，那么你显然不关心未来的更新 去图书馆。如果您关心更新，那么只需链接即可 库并信任库维护者以维护稳定的API。
如果您不相信API保持稳定，那么您不能盲目 无论如何都要更新你自己的源代码副本，那么获得了什么？
总结一个问题：为什么有人想要保留一份副本 项目源代码中的库而不仅仅是链接 该库并要求它作为依赖？
如果唯一的答案是“不想要依赖”，那么为什么不呢 随应用程序分发库的副本，但保留它们 完全分开？
答案 0 :(得分：2)
在Subversion书中使用供应商分支来控制第三方依赖关系是discussed in some depth。据我了解，其基本优势是保证稳定的API和所有开发人员的库的一致性，以及在同一版本系统中控制内部自定义修改的能力。
答案 1 :(得分：1)
在我正在进行的项目中，我们已经获得了主要代码（在一个Subversion项目中）和来自各个地方的各种各样的库，这些库都在他们自己的Subversion模块中。 Visual Studio解决方案为每个项目维护单独的项目，并在最后将它们链接在一起。如果我们在Unix或类似操作系统上工作，我们也会做同样的事情。
我看到的唯一缺点是我有时会忘记更新其中一个更频繁更改的库，并且在我注意到之前我的代码不会编译。如果我们在同一模块中有库，那么我们就不会遇到这个问题。 （并不是说我会这样做。灵活性的提高以及使用不同主要项目的不同库的能力太强了。）
API在这里是一个红色的鲱鱼：要么保持不变，要么改变，如果它改变了，我们必须以任何方式更新主代码。源代码与二进制库的问题也是如此（要么我们用主项目编译它们，要么我们不编译它们。）