4

在“使用 Subversion 进行版本控制”中，Vendor Branches 部分为“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 时）？

4

3 回答 3

3

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

如果 libcomplex 任何东西，但微不足道，您将陷入依赖合并 + 升级的噩梦。

于 2012-02-16T09:55:36.603 回答
1

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

一种完全不同的方法是将库（或其子集）编译成二进制文件，然后只将该二进制文件提交到源代码树中。这就是我在我从事的一个项目中所做的。我们为来自供应商的库提供了一个单独的存储库。一个自定义的 makefile 将构建svn://vendor_repo/trunk和生成svn://vendor_repo/trunk/libs（与每个新的 drop 一起提交），libs我们使用svn:externals. 使用这种方法，我们的代码不知道（或关心）这些库是一个子集还是整个库。他们所看到的只是一个要链接的二进制文件。我们必须手动维护的代码范围是我们用来构建供应商库的自定义 makefile。

于 2012-02-23T00:07:22.660 回答
0

您使用稀疏目录。

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

于 2012-02-19T13:14:39.207 回答