当项目需要成为2个不同.NET解决方案的一部分时，如何处理SVN？

Question

我一直在研究包含多个项目的.Net C＃解决方案（A）。 该解决方案通过SVN进行源控制。

现在我想开始研究一个新的解决方案（B），其中包括解决方案A的一个项目。此解决方案B也需要通过SVN进行源控制。

最明显的解决方案是创建解决方案B并仅包含相关项目。 如果我这样做，相关的项目将是2个不同的SVN文件夹的一部分。我想这会产生大量后续问题吗？

另一种解决方案是从解决方案A SVN文件夹中删除项目，并为项目创建专用的SVN文件夹。然后我可以从解决方案A和B更新这个项目代码。唯一不足的是，当我更新解决方案A（或B）时，我需要提交解决方案A（或B）和项目SVN文件夹的更改。但可能比以前的解决方案更好？

有没有其他选择？在这种情况下，最佳做法是什么？

感谢你的知识。

Answer 1

最佳做法取决于您的需求。

你的第一个想法是：

  

创建解决方案B并只包含相关项目

不会在SVN端产生任何问题：SVN不会知道A和B共享一个子项目（从现在开始SS）。 因此，如果您可以/想要将两个SS维护为不同的项目，那么您可以做到这一点并且您没有任何缺点。 相反，如果您需要/想要将SS作为“同一个项目”进行管理，则必须在本地副本上手动更新它，然后在每次在A或B上进行SS修改时提交SVN。 / p>

如果你必须将SS作为“同一个项目”进行管理，那么最好的解决方案就是你的第二个：

  

从解决方案中移除项目SVN文件夹并为项目创建专用的SVN文件夹

在这种情况下，SS代码将真正相同并真正共享。为了帮助结帐，更新和提交，您可以创建一些批处理脚本以使其更舒适......

希望这有帮助

Answer 2

我会考虑通过nuGet包打包共享项目。

这样你就有3个subversion文件夹（a，b，共享）。 Shared是一个解决方案（有自己的测试等），它可以输出到NuGet包，你需要时将它发布到（本地）网络文件夹。

解决方案A和B将引用打包的库，包括其修订控制。