Question

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

我的问题是你如何处理既有稳定版本又想要整合的alpha / beta分支的供应商分支？

所以，请说你按照SVN书中的原始例子。你有：

的svn：//本地主机/家庭/ SVN /供应商/ libcomplex的/电流
SVN：//localhost/home/svn/vendor/libcomplex/1.0
svn：//localhost/home/svn/vendor/libcomplex/1.1（与当前相同）

现在，假设您有两个版本的自己的'calc'应用程序：

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

让我们说calc-1.0使用libcomplex 1.0和calc（在trunk中）使用了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。

Answer 1

建议的做法是为您的版本创建一个分支。这样，您在主干中对供应商文件夹所做的更改无关紧要。然后，您可以使用1.0版本的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标签（请参阅complex tags）。它们允许您混合和匹配版本，因此您可以在技术上创建一个标记来表示使用旧版本的libcomplex的calc 1.0的补丁版本。

Answer 2

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

鉴于此，问题的答案变得相当清楚。为了发布1.0,1.1和1.0.1，供应商可能拥有1.0.x bugfixed版本的分支，同时继续在其主干上运行1.1及更高版本。我们的供应商分支应该反映这种设置。

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

Answer 3

我的工作方式与外部库一样：

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

导入后vendor/<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版本时，我只需将该属性编辑到另一个地方并运行update。这样做的结果是，即使我在WC上更改了一些文件，我也不会意外地将任何内容提交给libcomplex树的一部分。我必须在该目录下或特别提交更改。

现在，我的项目的升级，修复，分支很容易转移到新的libcomplex版本，而不是初始合并到mypathed-vendor。我所有的项目分支只需要改变和测试。此外，为我的项目获取库依赖项相对容易恕我直言。

关于外部的最后一个好处是，当启动一个新项目并且上游也大量开发并使用svn时，如果不需要修补该库，则可以将上游引用为外部。当上游中断您的项目时，您可以使用-rNUM选项保持上游版本一段时间，例如：

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

svn：externals的一个明显缺点是，必须使用来自项目的所有结帐变体的相同URI访问外部URL。

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

在SVN中处理供应商分支分支的最佳方法是什么？

3 个答案: