我一直致力于开发一个包含多个项目的 .Net C# 解决方案 (A)。 此解决方案通过 SVN 进行源代码控制。
现在我想开始研究一个新的解决方案 (B)，其中将包括解决方案 A 的一个项目。这个解决方案 B 也需要通过 SVN 进行源代码控制。
最明显的解决方案是创建解决方案 B 并仅包含相关项目。 如果我这样做，相关项目将成为 2 个不同 SVN 文件夹的一部分。我想这会产生大量后续问题？
另一种解决方案是从解决方案 A SVN 文件夹中删除项目，并为该项目创建一个专用的 SVN 文件夹。然后我可以从解决方案 A 和 B 更新此项目代码。唯一的缺点是当我更新解决方案 A（或 B）时，我需要为解决方案 A（或 B）和项目 SVN 文件夹提交更改。但可能比以前的解决方案更好？
还有其他选择吗？在这种情况下，最佳做法是什么？
谢谢你的知识。
【问题讨论】：
最佳实践取决于您的需求。
您的第一个想法是：
创建解决方案 B 并仅包含相关项目
不会在 SVN 方面产生任何问题：SVN 不会知道 A 和 B 正在共享一个子项目（从现在开始 SS）。 因此，如果您可以/想要将两个 SS 维护为不同的项目，您可以这样做，并且不会有任何缺点。 相反，如果您需要/想要将 SS 管理为“同一个项目”，则必须在本地副本上手动更新它，然后每次在处理 A 或 B 时对 SS 进行修改时提交到 SVN。
如果您必须将 SS 作为“同一个项目”来管理，那么最好的解决方案是您的第二个：
从解决方案 A SVN 文件夹中删除项目并为该项目创建一个专用的 SVN 文件夹
在这种情况下，SS 代码实际上是相同的并且是真正共享的。为了帮助结帐、更新和提交，您可以创建一些批处理脚本以更舒适...
希望对你有帮助
【讨论】：
我会考虑通过 nuGet 包打包共享项目。
这样您就有 3 个颠覆文件夹（a、b、共享）。 Shared 是一种解决方案（带有自己的测试等），它（可以）输出到 NuGet 包，您可以在需要时将其发布到（本地）网络文件夹。
解决方案 A 和 B 将引用打包的库，包括它们的版本控制。
【讨论】：