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

因此，我已经熟悉了这一点：

我的问题是，如何处理既有稳定版本又有希望集成的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==计算2.0）
calc-1.0（向公众发布）

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

libcomple1.0中有一个bug，发布了一个新版本来修复这个bug：libcomple1.0.1。libcomplex维护人员还将此错误修复包含在libcomplex 1.1中

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

它去哪里了

你不能把它放在一边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

建议的做法是为您的发行版创建分支。这样，无论您在主干中对供应商文件夹做了什么更改。然后可以使用libcomplex的1.0.1版本更新1.0发行版分支，这不会影响trunk（calc2.0）

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

下一步要做的是不要有“电流”。只需直接参考您正在使用的版本即可。例如，将文件夹结构保留为：

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

永远不要覆盖这些文件。然后，Calc2.0可以引用libcomplex的1.1版，Calc1.0可以引用1.0.1版

---

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

供应商分支背后的想法似乎是，它们应该反映供应商自己的存储库可能是什么样子。因此，

current

表示供应商的主干，标记的版本表示供应商自己的标记，在每个版本发布时创建

有鉴于此，问题的答案变得相当清楚。为了发布1.0、1.1和1.0.1，供应商可能有一个1.0.x bugfixed版本的分支，同时继续在主干上处理1.1和更高版本。我们的供应商分支应镜像此设置

---

也就是说，对于1.0.x bugfixed版本，我们还需要一个分支（在我们的供应商分支内）。它应该在包含1.0时从current创建，可以命名为

current-1.0.x

。然后可以更新此分支以保存1.0.1，然后可以像往常一样将其标记并复制到我们自己的树中。

我使用外部库时是这样工作的：

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//

在导入后不会更改，而mypatched vendor是使用

svn cp vendor//mypatched vendor//

启动的

现在diffing

vendor/libcomplex/1.0 mypatched vendor/libcomplex/1.0

应该为您提供要合并到刚刚导入的

1.0.1

版本的补丁

我可能是少数，但我喜欢房地产。相当多的IDE不喜欢它们，所以要谨慎使用。原因是这样的。我现在可以编辑我的主项目：

签出项目/myProject/trunk到myprj trunk

在签出运行中

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

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

现在，我的项目的升级、修复和分支可以轻松地移动到新的libcomplex版本，而无需与mypathed供应商进行初始合并。我所有的项目分支只需要修改和测试。此外，在IMHO中，获得项目的库依赖项也相对容易

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

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

svn:externals的一个明显缺点是，必须使用项目的所有签出变体中的相同URI访问externals url

---

但是使用externals允许您将供应商回购与项目回购分开。

在我前面的示例中，我的发行版有一个分支：calc 1.0。供应商文件夹不包含在calc下。您是否建议也分支/vendor？这里要明确的是，我正在描述的示例：/vendor/libcomplex//calc/trunk//calc/branchs/1.0/您不使用“current”而只使用文件夹结构的建议将无法正确地将版本之间的更改合并到trunk中，从而无法达到目的。您需要此更改历史记录，以便将更改合并到您已修改原始供应商源代码的主干中。我的方法适用于只使用已发布版本的情况。如果您也在修改源代码，那么将供应商代码视为您自己的代码（即将其包含在主干分支中，而不是将供应商作为单独的文件夹）可能会很有用。然而，您的方法也有意义。Cre