9

所以，我已经很熟悉了：
http ://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

我的问题是您如何处理同时具有稳定版本和您想要集成的 alpha/beta 分支的供应商分支？

因此，假设您遵循 SVN 书中的原始示例。你会有：

svn://localhost/home/svn/vendor/libcomplex/current
svn://localhost/home/svn/vendor/libcomplex/1.0
svn://localhost/home/svn/vendor/libcomplex/1.1（与当前相同）

现在，假设您有两个版本的自己的“计算”应用程序：

calc（这本质上是trunk == calc 2.0）
calc-1.0（向公众发布）

假设 calc-1.0 使用 libcomplex 1.0，而 calc（在主干中）使用仍在开发中的 libcomplex 1.1。

libcomplex 1.0 中有一个错误，并且发布了一个新版本来修复该错误：libcomplex 1.0.1。libcomplex 维护者也将此错误修复包含在 libcomplex 1.1 中。

您还没有准备好发布 calc 2.0，因此您需要将 libcomplex 1.0.1 集成到您的供应商分支中，然后更新 calc-1.0 以发布错误修复版本。

它去哪儿了？

你不能把它放在 svn://localhost/home/svn/vendor/libcomplex/current 因为 1.1 目前在那里。

您是否将 svn://localhost/home/svn/vendor/libcomplex/1.0 复制到 svn://localhost/home/svn/vendor/libcomplex/1.0.1 然后引入新版本？这样你就可以使用 svn 将 1.0 和 1.0.1 之间的差异合并到 calc-1.0。

4

3 回答 3

3

推荐的做法是为您的版本创建一个分支。这样，您在主干中对供应商文件夹进行的更改都无关紧要。然后，您可以使用 1.0.1 版本的 libcomplex 更新 1.0 发布分支，这不会影响主干（计算 2.0）。

但是，如果 calc 1.0 和 calc 2.0 在同一个分支中并存，这将不起作用。

接下来要做的是没有“当前”。直接参考您使用的版本即可。例如，将您的文件夹结构保留为：

vendor/libcomplex/1.0
vendor/libcomplex/1.1
vendor/libcomplex/1.0.1

并且永远不要覆盖这些文件。那么calc 2.0可以参考libcomplex 1.1版本，calc 1.0可以参考1.0.1。

您的最后一个选项（并不是真正推荐）是使用 svn 标签（请参阅复杂标签）。它们允许您混合和匹配版本，因此您可以在技术上创建一个标签来表示您的 calc 1.0 的补丁版本与旧版本的 libcomplex。

于 2009-08-15T05:36:34.140 回答
2

我像这样使用外部库：

project/myProject/{branches,trunk}
vendor/libcomplex/1.0 
vendor/libcomplex/1.0.1
vendor/libcomplex/2.0.0
mypatched-vendor/libcomplex/1.0
mypatched-vendor/libcomplex/1.0.1
mypatched-vendor/libcomplex/2.0.0

导入后wherevendor/<lib>/<version>永远不会改变，并且 mypatched-vendor 以svn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version>.

现在差异vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0应该给你补丁合并到刚刚导入的1.0.1版本。

我可能是少数，但我喜欢svn:externals属性。相当多的 IDE 不喜欢它们，因此请谨慎使用。原因是这样的。我现在可以编辑我的主要项目：

checkout project/myProject/trunk to myprj-trunk在你检查运行。

svn propedit svn:externals .
# with
libcomplex  URLTO/mypatched-vendor/libcomplex/1.0

当我想测试一个新的 lib 版本时，我只需将该属性编辑到另一个地方并运行更新。这也有这样的效果，即使我在 WC 上更改了一些文件，我也不会意外地向树的 libcomplex 部分提交任何内容。我必须在该目录下或专门在那里提交更改。

现在，我的项目的升级、修复、分支很容易移动到新的 libcomplex 版本，而无需最初合并到 mypathed-vendor。我所有的项目分支只需要 propchange 和测试。恕我直言，为我的项目获取库依赖项也相对容易。

关于 externals 的最后一个好处是，当开始一个新项目时，upstream 也被大量开发并使用 svn，如果您不需要修补该库，您可以将 upstream 作为外部引用。当上游破坏您的项目时，您可以使用 -rNUM 选项将上游版本保留一段时间，例如：

libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk

svn:externals 的一个明显缺点是必须可以从项目的所有结帐变体中使用相同的 URI 访问 externals url。

但是使用 externals 可以让您将供应商repo 与您的项目repo分开。

于 2012-02-18T09:24:55.747 回答
2

供应商分支背后的想法似乎是它们应该反映供应商自己的存储库的样子。所以，current代表厂商的主干，而标记的版本代表厂商自己的标签，在每个版本发布时创建。

鉴于此，问题的答案变得相当清楚。为了发布 1.0、1.1 和 1.0.1，供应商大概有一个 1.0.x 错误修复版本的分支，同时继续在他们的主干上开发 1.1 和更高版本。我们的供应商分支应该反映这个设置。

也就是说，我们还需要一个分支（在我们的供应商分支中）用于 1.0.x 错误修复版本。这应该是在它包含 1.0 时从当前创建的，并且可以命名为current-1.0.x. 然后可以更新此分支以保存 1.0.1，然后可以像往常一样标记并复制到我们自己的树中。

于 2012-02-17T05:56:32.900 回答