svn供应商分公司

在中，在“供应商分支”一章中，建议维护当前/包含最新版本的第三方产品，因此从示例中我们得出：

   repos/vendor/libcomplex/current - contains 1.1
   repos/vendor/libcomplex/1.0
   repos/vendor/libcomplex/1.1 

当前/的目的是什么？为什么我们最初需要将一个新版本放到current/中，然后才需要将current/复制到一个版本专用目录（例如1.1）中

我猜是为了：

使不同版本的svn具有可比性

另一方面，版本以更高效的方式存储在svn存储库中

我可以绕过当前/供应商分支中的处理吗

更新：

---

我不打算修补供应商代码（至少这是一个计划）。因此，我将使用svn:external来使用适当的供应商版本

之所以需要它，是因为使用svn\u load\u dirs.pl脚本可以销毁该目录的内容，并将所有内容作为新内容导入

不，你不能绕过它，因为它是必要和有用的

这一点是在删除的目录和文件在新的供应商下降相对于旧的。此脚本处理将新供应商放入当前文件，然后每隔一个不存在的文件/dir“自动手动”删除。然后合并

svn\u加载\u目录pl

包含多个 几乎没有删除、添加和移动 使升级到的过程复杂化 每个连续版本的 第三方数据

---

除了AlberT的评论之外，如果您的构建脚本要引用一个您应该经常看到最新供应商代码的区域，那么拥有一个专用目录（当前）也有助于拥有一个恒定的路径引用

使用/vendor/current分支会使/vendor/tag分支成为纯卷影副本

---

我还将当前分支用于供应商的主要版本之间的非常次要的版本，我认为不需要添加标签。

供应商分支管理方案的目的是将第三方产品的版本放入存储库，以便您在版本之间建立历史记录。如果只将1.0版导入到

repos/vendor/libcomplex/1.0

，并将1.1版导入到

repos/vendor/libcomplex/1.1

，则1.0版和1.1版之间的Subversion将没有历史记录，并且您将无法在Subversion中查看1.0版和1.1版之间的更改。当然，您可以同时签出这两者并使用GNU diff来比较它们，但在这种情况下，您并没有利用Subversion的强大功能

如果要创建自己的分支并希望将1.0和1.1之间的更改合并到分支中，则历史记录非常重要。如果您希望查看Subversion版本1.0和1.1之间的更改，历史记录也将导入。最后，拥有一个历史记录会导致更有效地存储数据，因为只存储1.0和1.1之间的增量

---

通过将1.0版导入到

repos/vendor/libcomplex/current

，然后将1.1版添加到同一目录，您可以在1.0和1.1之间建立一个历史记录。

好的，您说的是svn\u load\u dirs.pl需要current/。但我不想用它。事实上，如果我正确理解了svn手册，那么特别引入该脚本是为了克服由于建议的维护供应商DROP模式而产生的困难。同样，我不打算在我的代码中直接引用当前版本，只使用版本删除（例如repos/vendor/libcomplex/1.1）。那么，在这种情况下我真的需要current/吗？你真的需要一个目录来进行供应商删除导入！当然，你想怎么说就怎么说。但是您需要一个进行导入的位置，这个位置不能直接作为目标目录。如果您不使用current，那么不同的供应商drop之间就没有任何关联，因此在svn repo中使用它们没有多大意义，使用它将lib导入到项目中就足够了。