Svn Subversion：仅使用来自供应商分支的部分文件

在“”中，为“libcomplex”设置供应商分支，然后使用以下命令将libcomplex复制到主开发分支中：

$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
           http://svn.example.com/repos/calc/libcomplex        \
           -m "bringing libcomplex-1.0 into the main branch"

然而，如果我们只需要libcomplex的一个子集功能（因此也是文件的一个子集），该怎么办

---

只将libcomplex的一部分复制到主分支中可以吗？或者这可能会导致问题（特别是在升级libcomplex时）？

我不建议拆分从其他源导入的库

如果librame很复杂，但很琐碎，那么您将陷入依赖项合并+升级的噩梦

您可以使用

---

目前，它更适合于提取目录而不是单个文件，但假设这样做没有问题，请使用--depth选项限制签出的内容量。

也许最简单的方法是首先只将需要的文件提交到存储库中。这使得问题的颠覆方面变得微不足道。如果您可以编写一个脚本，从您从供应商处获得的drop中提取所需的库子集，那么整个过程都可以自动化。如果提取必须手动完成，这仍然是可行的，但这有点烦人。不管是哪种方式，它都很可能会变成一个维护头疼的问题。第三方库通常不会被拆分，因此每当库进行任何结构更改时，您都可能不得不进行手动更改

---

另一种完全不同的方法是将库（或其子集）编译成二进制文件，然后只将该二进制文件提交到源代码树中。这就是我在一个项目上所做的。我们为来自供应商的库提供了单独的存储库。自定义生成文件将生成

svn://vendor_repo/trunk

并生成

svn://vendor_repo/trunk/libs

（与每个新的拖放一起提交），我们使用

svn:externals

将这个

libs

子文件夹拉入主存储库。使用这种方法，我们的代码不知道（或关心）libs是一个子集还是整个库。他们看到的只是一个要链接的二进制文件。我们必须手动维护的代码范围是我们用于构建供应商库的自定义makefile。

除了您不希望这些文件出现在树上之外，还有其他原因吗？Cherry为安装或发布包挑选文件是另一回事。OP在分支之间的存储库中进行复制，而不是签出。