我的情况：我有几个组件，有时会对它们进行更改，并在很多不同的项目中共享。每个项目都将这些文件放在名为/ depends的子文件夹中。依赖包含所有常见组件的一堆svn外部。
svn：externals给我带来了很多时间和痛苦。
请记住，我有几个项目（假设每个项目使用相同的外部设置，这就是10个），因此为每个项目保留正常的已提交目录会花费我很多合并时间。
对我的情况有更好的选择吗？
答案 0 :(得分：12)
我认为部分问题是共享组件的发布周期不一定与项目的发布周期相匹配。
此处描述的共享组件有自己的发布周期。换句话说，每个项目都可以作为一个单独的项目（或者可能是作为一个单独的项目进行管理的集合）进行管理，其中包含发布/版本号。
请注意，svn:externals定义可以包含特定版本。
这允许使用共享组件的每个项目针对该共享组件（或共享组件的集合）的特定发行版/修订版进行开发，从而提供一组稳定的项目的依赖项。对组件的更改不会破坏项目，因为每个项目都在查看组件的特定修订，而不一定是HEAD上的trunk。
虽然这可能看起来更像是前期工作，但我相信从长远来看，这种做法可以为这种情况提供更好的变更管理流程。
答案 1 :(得分：6)
我同意@Ken。
我非常强烈建议使用svn:externals 反对，而不进行特定修订。如果没有修订版，则不可能重新创建旧的结帐。如果您只在标记时固定外部，则只能重新创建标记的内容。如果你想在trunk中重新创建一些中间版本，你就可以自己动手了。
不分支外部的一个原因是不清楚应该怎么做。如果项目A的外部指向标签/ 2.0.0并且您正在为项目创建3.4.x分支，那么项目A的外部应该指向什么？应该投射A分支吗？如果是这样，到什么版本？
如果项目具有不同的发布周期，则在分支时通常无法为外部定义合理的行为。
（如果您尚未（包含在Subversion源代码分发版中）允许您在标记期间固定外部，则可能需要查看svncopy.pl脚本。）
我们发现svn：externals在用于将您正在积极开发的一组组件放在一起时效果很差。外部效果很好，可以引入不会移动很多的外部组件，并且不会出现分支问题。
答案 2 :(得分：5)
我在类似的question上说过这个：
您应该使用svn:externals作为来自不同存储库的外部引用。所以svn:externals应该引用位于不同存储库中的组件，模块，第三方工具等。
您应不使用svn:externals来模拟“符号链接” - 使用外部指向同一存储库的行为。
您可以通过修改构建结构或使用checkout-scripts和稀疏结帐功能来解决此类问题。
svn：外部有很多问题，大多数都难以看到，跟踪和修复： see an example here
如果使用外部指向其他存储库，则大多数情况下您都不会遇到这些问题。
答案 3 :(得分：2)
您可以尝试使用所谓的供应商分支：
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.vendorbr
当您处理第三方库时，它是一种有用的策略，但它在像您这样的情况下也很有用。
答案 4 :(得分：0)
svncopy.pl（在this question中提到）会将svn:externals中的路径重写为分支中的新位置。