在 SVN 中处理供应商分支的最佳方式是什么？
所以，我已经熟悉了：
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”应用程序的两个版本：
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 中。
So, I'm already familiar with this:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
My question is how do you handle a vendor branch that has both a stable release and an alpha/beta branch that you want to integrate?
So, say you follow the original example from the SVN book. You'd have:
svn://localhost/home/svn/vendor/libcomplex/current
svn://localhost/home/svn/vendor/libcomplex/1.0
svn://localhost/home/svn/vendor/libcomplex/1.1 (same as current)
Now, say you have two versions of your own 'calc' app:
calc (this is essentially trunk == calc 2.0)
calc-1.0 (released to public)
Let's say calc-1.0 uses libcomplex 1.0 and calc (in trunk) used libcomplex 1.1, which is still being developed.
There's a bug in libcomplex 1.0 and a new version is released to fix that bug: libcomplex 1.0.1. The libcomplex maintainers have also included this bugfix into libcomplex 1.1.
You're not ready to release calc 2.0, so you need to integrate libcomplex 1.0.1 into your vendor branch and then update calc-1.0 to make a bug-fix release.
Where does it go?
You can't put it at svn://localhost/home/svn/vendor/libcomplex/current because 1.1 currently lives there.
Do you copy svn://localhost/home/svn/vendor/libcomplex/1.0 to svn://localhost/home/svn/vendor/libcomplex/1.0.1 and then bring in the new release? That way you could use svn to merge the diff between 1.0 and 1.0.1 to calc-1.0.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
推荐的做法是为您的版本创建一个分支。这样，您在主干中对供应商文件夹进行的任何更改都无关紧要。然后，您可以使用 1.0.1 版本的 libcomplex 更新 1.0 版本分支，这不会影响主干 (calc 2.0)。
然而，如果 calc 1.0 和 calc 2.0 在同一个分支中并存，则这将不起作用。
接下来要做的就是不要有“当前”。只需直接参考您正在使用的版本即可。例如，将您的文件夹结构保留为：
并且永远不要覆盖这些文件。那么calc 2.0可以引用libcomplex的1.1版本，calc 1.0可以引用1.0.1。
您的最后一个选择（并不真正推荐）是使用 svn 标签（请参阅 复杂的标签）。它们允许您混合和匹配版本，因此您可以在技术上创建一个标签来表示 calc 1.0 的补丁版本与旧版本的 libcomplex。
The recommended practice is to create a branch for your release. That way, it doesn't matter what changes you make in trunk to your vendor folders. You can then update the 1.0 release branch with the 1.0.1 version of libcomplex, and that would not have affected trunk (calc 2.0).
This won't work if calc 1.0 and calc 2.0 live side by side in the same branch however.
The next thing to do is to not have "current". Just refer directly to the version that you are using. eg, leave your folder structure as:
and never overwrite these files. Then calc 2.0 can refer to version 1.1 of libcomplex, and calc 1.0 can refer to 1.0.1.
Your last option, (and not really recommended), is to use svn tags (see complex tags). They allow you to mix and match versions, so you could technically create a tag to represent the patch release of your calc 1.0 with the old version of libcomplex.
供应商分支背后的想法似乎是它们应该反映供应商自己的存储库的样子。因此，
current代表供应商的主干，标记版本代表供应商自己的标签，在每个版本发布时创建。考虑到这一点，问题的答案就变得相当清楚了。为了发布 1.0、1.1，然后是 1.0.1，供应商可能有一个 1.0.x 错误修复版本的分支，同时继续在其主干上开发 1.1 及更高版本。我们的供应商分支应该镜像此设置。
也就是说，我们还需要一个 1.0.x 错误修复版本的分支（在我们的供应商分支内）。它应该是从包含 1.0 时的 current 创建的，并且可以命名为类似于
current-1.0.x的名称。然后可以更新该分支以保存 1.0.1，然后可以像往常一样对其进行标记并复制到我们自己的树中。The idea behind vendor branches seems to be that they should reflect what the vendor's own repository might look like. So,
currentrepresents the vendor's trunk, and the tagged versions represent the vendor's own tags, created when each version is released.Given this, the answer to the question becomes fairly clear. In order to have released 1.0, 1.1 and then 1.0.1, the vendor presumably has a branch for 1.0.x bugfixed versions while continuing to work on 1.1 and later versions on their trunk. Our vendor branch should mirror this setup.
That is, we also need a branch (within our vendor branch) for 1.0.x bugfixed versions. This should be created from current at the time when it contained 1.0, and may be named something like
current-1.0.x. This branch can then be updated to hold 1.0.1, which can then be tagged and copied into our own tree as usual.我与外部库的工作方式如下：
其中
vendor// 在导入后永远不会更改，并且 mypatched-vendor 是通过svn cpvendor/启动的。 /<版本> mypatched-vendor// .现在，比较
vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0应该会为您提供要合并到刚刚导入的1.0.1版本的补丁。我可能是少数，但我喜欢 svn:externals< /a> 属性。很多 IDE 不喜欢它们，因此请谨慎使用。原因是这样的。我现在可以编辑我的主项目：
在签出运行中
checkout project/myProject/trunk to myprj-trunk。当我想测试新的库版本时，我只需将该属性编辑到另一个位置并运行更新即可。这还有一个效果，即使我更改了 WC 上的某些文件，我也不会意外地将任何内容提交到树的 libcomplex 部分。我必须在该目录下或专门在那里提交更改。
现在，我的项目的升级、修复和分支可以轻松移动到新的 libcomplex 版本，而无需进行初始合并到 mypathed-vendor 的操作。我的所有项目分支只需要 propchange 和测试。恕我直言，获取我的项目的库依赖关系也相对容易。
关于外部的最后一个好处是，当开始一个新项目时，上游也得到了大量开发并使用 svn，如果您不需要修补该库，您可以将上游引用为外部。当上游破坏您的项目时，您可以使用 -rNUM 选项将上游版本保留一段时间，例如：
svn:externals 的一个明显缺点是必须使用项目的所有结账变体中的相同 URI 访问外部 url。
但是使用外部可以让您将供应商存储库与您的项目存储库分开。
I work like this with external libraries:
Where
vendor/<lib>/<version>is never changed after import and mypatched-vendor is started withsvn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version>.Now diffing
vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0should give you patches to be merged to the just imported1.0.1version.I'm probably in the minority, but I like svn:externals properties. Quite many IDEs don't like them so use with discretion. The reason is this. I can now edit my main project:
checkout project/myProject/trunk to myprj-trunkin you check out run.When I want to test a new lib version I simply edit that property to another place and run update. This has also the effect that I don't accidentally commit anything to libcomplex part of the tree even if I've change some files on WC. I have to be under that directory or specially commit changes there.
Now upgrading, fixes, branches of my project are easily moved to new libcomplex versions without more than the initial merge to mypathed-vendor. All my project branches only need propchange and testing. Also it's relatively easy to get library dependencies for my projects IMHO.
The last nice thing about externals is that when starting a new project and upstream is also heavily developed and uses svn you can reference upstream as external if you don't need to patch that library. And when upstream breaks your project you can hold upstream version for a while with -rNUM options like:
One definite drawback to svn:externals is that the externals url has to be accessible with the same URI from all checkout variants of your project.
But using externals allows your to keep vendor repo separate from your project repo.