我正在将客户的 SourceSafe 存储库（3 个项目）迁移到 SVN，其中两个项目共享源文件。（这些项目是独立的产品 - 具有不同的名称和发布版本等）
SVN 解决了这个缺点吗？人们通常如何处理这种情况？
我知道/能想到的选项
对 SVN 使用 external 或 extern 或其他任何东西。我听说由于各种原因这不是一个好选择
创建一个包含源的新项目（可能称为共享）。这样做的问题是我们仍然必须获取该代码（它不是库）并以某种方式将其导入项目中。可以证明它与上述问题相同，并且引入了额外产品/项目的开销。
只需签入两个存储库中的文件并交叉更新它们。这要求开发人员了解共享并记住签入。我想我可以编写一个脚本来检查所有已知的共享文件并在需要时更新它们。
为共享的两个项目提供一个存储库。这让我不得不创建一个包含两者的顶级项目/存储库，这是一个标签问题。我真的不想给顶级伪项目贴上标签。（标签、主干和分支的东西并不是我想要的。）
我可能会选择最后一个选项。
还有其他意见吗？
我不知道你到底听说了什么关于 svn:externals，但我认为这就是你应该在这里使用的。您甚至可以指定外部指向共享源的稳定分支或发布标签，甚至指向使用它的其他两个项目的两个不同标签（如果您尽快修复共享代码中的一些错误，您可能需要这个对于项目 A，但您没有足够的时间使用项目 B 对其进行全面测试）。
您可以做的最糟糕的事情是您的选项 3（交叉更新相同文件的两个版本）。
安全的方法是拥有第三个项目，将共享源构建到其他两个使用的库中。该库项目有它自己的 SVN 存储库。
您甚至可以对只是标题的共享文件执行此操作，只需将它们留在 lib 项目目录中并将其添加到包含列表中即可。
在两个项目中拥有相同的文件，即使使用 soruce 控制也迟早会自找麻烦！
当然，使用一个存储库。稍后可能会有更多共享代码。
标签到底有什么问题？因此，您在标签中有一个额外的文件夹，但它不会占用您的空间。如果你真的不想要那个额外的文件夹，这里有一个组织树的想法：
也就是说，当你要标记 prj1 时，你创建 tag1，然后将 prj1 复制并共享到其中。
根据我的经验，让两个独立的项目引用相同的源文件是有问题的，因为我可能会在共享文件中添加或更改代码以满足一个项目的需求，而只是破坏另一个构建。
似乎这里的技巧是允许每个项目独立推进，因此无论您如何设置存储库，您都希望稳定共享代码，使其仅在您需要时更改。
例如，如果共享代码位于同一存储库的两个分支/文件夹中，或者如果它被单独检查到两个不同的存储库中，或者如果它单独位于第三个存储库中，则您需要升级那段代码的步骤成为没有副作用的手动工具，您可以对其进行隔离、调试和错误修复。
我已将此代码分解到第三个存储库中，然后我定期将该代码迁移到我的依赖项目存储库中，作为内部发布和升级步骤；然后我的个人项目有一个看起来像“升级到 Shared.App.dll 的 v4.3.345”的修订版，其中包括针对该版本工作所需的所有更改。
如果共享代码与两个依赖项目属于同一个存储库，则在每个项目中都有一个单独的副本，并使用存储库合并来传播您的更改。
您没有提及您正在使用什么语言或构建工具，但对于 Java 项目，Maven 可能值得研究。特性之一是本质上扩展了 ant 以允许您引入外部依赖项。这消除了您对必须创建、维护和标记元项目的担忧之一。它还允许您从外部项目的 HEAD 中提取，或者从给定的标签中提取，这减轻了之前发布者关于在项目之间共享公共文件并无意中导致损坏的担忧之一，因为您可以控制每个项目何时使用独立的共享文件的较新版本。
使用触发器更新文件听起来是个坏主意。不知何故，他们会失去同步。真正使用共享代码的解决方案是将其提取到一个库中并在多个解决方案中使用该库。不过，这听起来超出了您的项目范围，因此最后一个解决方案是您最好的选择。
为共享的两个项目提供一个存储库。这让我不得不创建一个包含两者的顶级项目/存储库，这是一个标签问题。我真的不想给顶级伪项目贴上标签。（标签、主干和分支的东西并不是我想要的。）
像其他人一样，我肯定会用最后一种方式。您觉得“只有”一个存储库有什么问题？存储库是关于管理员权限的。除此之外，我会看到一个仓库中有任意 N 个项目。