我的情况是：我有几个组件，它们有时会发生变化，并在许多不同的项目中共享。每个项目将这些组件放在一个名为/depends的子文件夹中。/depends包含了我们所有常见组件的一堆svn外部链接。
svn:externals 给我带来了很多时间和痛苦。
请记住，我有几个项目（假设本次讨论有10个），每个项目都使用相同的外部链接，因此为每个项目保留常规提交的目录将花费我很多合并时间。
在我这种情况下是否有更好的替代方案？
我认为问题的一部分在于共享组件的发布周期不一定与项目的发布周期匹配。
如此描述的共享组件 具有其自身的发布周期。换句话说，每个共享组件都可以作为一个单独的项目进行管理（或者也可以将它们的集合视为一个单独的项目），并拥有自己的版本号和发布编号。
请注意，svn:externals 定义可以包括一个 特定版本号。
这允许使用共享组件的每个项目针对该共享组件的特定版本/修订版进行开发（或者是共享组件集合），为项目提供了稳定的依赖关系。组件的更改不会破坏项目，因为每个项目都查看特定版本的组件，而这个版本不一定是trunk上的HEAD。
虽然这可能会看起来需要更多的前期工作，但我相信从长远来看，这种做法为这种情况提供了更好的变更管理流程。
我同意@Ken的看法。
强烈建议不要在没有特定版本的情况下使用svn:externals。没有版本，就无法重现旧的检出。如果只在标记时固定您的外部文件，则只能重新创建您已标记的内容。如果您想重新创建主干中的某个中间版本，则需要自己解决。
不将外部文件分支化的原因之一是不清楚该如何做。如果您将项目A中的外部文件指向tags/2.0.0，并为项目创建3.4.x分支，则项目A的外部文件应该指向什么？项目A是否也应该分支？如果是这样，它应该分支到哪个版本？
如果这些项目具有不同的发布周期，则通常无法定义外部文件在分支时的合理行为。
（如果您尚未了解svncopy.pl脚本，请查看一下（包含在Subversion源发行版中），该脚本允许您在标记期间固定外部文件。）
我们发现，当用于保持您正在积极开发的一组组件时，svn:externals的效果非常差。外部文件适用于引入很少移动且不存在分支问题的外部组件。
svn:externals作为来自不同存储库的external引用。因此，svn:externals应该指向位于不同存储库中的组件、模块、第三方工具等。svn:externals通过使用外部引用来指向同一个存储库来模拟“符号链接”行为。
大多数情况下，您可以通过修改构建结构或使用检出脚本和稀疏检出功能来解决此类问题。
svn:externals存在很多问题，其中大多数难以看到、跟踪和修复：
在这里查看一个例子