【问题标题】:Checking in subprojects of .net solution individually to SVN将.net解决方案的子项目单独签入SVN
【发布时间】:2016-08-08 20:05:46
【问题描述】:

我们目前有一个大型 C# 解决方案,由大约 40 个项目组成。

另一个客户的第二个解决方案几乎是相同的,并且使用了许多相同的项目,其中一些被省略了,还有一些在第一个解决方案中没有出现。

为了使代码版本更易于管理,我想将 SVN 解决方案中包含的每个项目作为单独的项目签入,但是我尝试过的所有 SVN 客户端似乎都不支持这一点,而无需依次手动添加每个项目。

期望的结果是:

1) 打开客户端 A 的解决方案,并更改一个通用项目 2) 提交更改,然后关闭解决方案。 3) 打开客户端 B 的解决方案。在“1”中所做的更改在客户端 B 解决方案中可用。 4) 对特定于客户 B 的项目进行更改。提交这些更改后,从“1”开始的更改不会显示为待处理。

我尝试过 AnkhSVN 和 VisualSVN,但在这两种情况下,选择项目并运行 Add selected projects to Subversion 让我可以选择添加根解决方案,但不能单独添加项目。

我设法得到的最接近的是 Tortoise,但这涉及手动添加每个项目,这对于这么多源项目来说是不可行的选择。

编辑:正如建议的那样,使用一个通用解决方案和两个单独的客户端特定解决方案可以解决将代码提交到 SVN 的问题,但需要针对必须提前编译的 DLL 进行编译。

我们最初确实尝试过这种方法,但由于 VS 有时无法正确重新加载 DLL 的问题,我们在调试时遇到了问题。

我不确定是否可以使用自动化流程以这种方式添加项目,但在我咬紧牙关编写一些代码之前,我会欢迎提出建议。

非常感谢。

【问题讨论】:

    标签: .net visual-studio svn visualsvn ankhsvn


    【解决方案1】:

    在这种情况下,我会推荐 3 个整体解决方案:

    1. 客户端 A 解决方案
    2. 客户端 B 解决方案
    3. 通用解决方案

    每个都可以由自己的存储库支持。现在您可以将您的通用代码发布为一组 dll(或者您可以通过设置私有 Nuget 服务器并将您的通用解决方案转换为 Nuget 包来获得幻想)并从客户端解决方案中引用它。

    【讨论】:

    • 我确实认为这是一种选择。问题是,当我们进行测试时,我们需要 IDE 中存在的整个解决方案的代码进行调试。最初,我们确实针对 DLL 进行了编译,但发现调试存在问题。到目前为止,通用代码的 Nuget 存储库最接近我想要实现的目标,但它仍然不完全存在。我不确定 SVN 是否曾被设计为以这种方式使用。
    • 这就是测试的用途:)
    • 是的,但目前,我们没有太多的代码库单元测试。我一直在努力重构它并将测试放在一起,但时间限制使得进展非常缓慢。我们使用构建脚本来生成最终版本,但这还没有将任何已编译的工件推送到服务器。本质上,我试图获得与 Maven 项目类似的行为(但没有 POM 地狱)。
    • 我硬着头皮写了一个工具来单独上传项目,忽略了解决方案。由于结构不太可能改变,这将在短期内起作用。从长远来看,测试套件和客户特定的解决方案是必经之路。
    猜你喜欢
    • 2012-03-20
    • 1970-01-01
    • 1970-01-01
    • 2012-10-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-05-25
    • 2020-05-12
    相关资源
    最近更新 更多