Mercurial：.NET 3.5 和 4.0 都存在的类库？答案

【问题标题】：Mercurial: Class library that will exist for both .NET 3.5 and 4.0?Mercurial：.NET 3.5 和 4.0 都存在的类库？
【发布时间】：2010-05-20 12:13:37
【问题描述】：

我有一个用 .NET 3.5 编写的相当大的类库，我想升级它以使其也可用于 .NET 4.0。

在这个过程中，我会剔除很多旧垃圾，并重写一些代码以更好地利用新类和 .NET 4.0（如 TPL）中的支持。类库将因此出现分歧，但仍然是非常相似，可以以相同的方式对两者进行一些错误修复。

我应该如何在 Mercurial 中最好地组织这个类库？如果这很重要，我正在使用 Kiln (fogbugz)。

我在想：

一个存储库中的命名分支，然后可以将任何错误修复从一个存储库移植到另一个存储库
一个仓库中的未命名分支，也可以移植，但是我觉得这样会比较乱
单独的存储库，必须重新实现错误修复（或使用非 Mercurial 集成的比较工具来帮助我）

你会怎么做？（我还没有想到的任何其他替代方案也是受欢迎的。）

请注意，类库在某些方面会有很大差异，我有一些旧的集合类型代码的残余，这些代码与我将删除的 Linq 类似，以及一些使用它的代码，我将重写以使用 Linq - 方法代替。因此，仅仅复制项目文件并使用#if NET40..#endif 部分是行不通的。此外，类库的 3.5 版本不会获得很多新功能，主要是关键的错误修复，因此保持两个版本同样“活跃”并不是真正必要的。因此，所有文件的单独副本就足够了。

编辑来自@Rudi的回答here，我想他的意思是这样的：

创建两个分支（或保留一个“默认”并为另一个路径创建另一个分支，在我的情况下是“默认”=.NET 4.0 和“net35”=.NET 3.5）
沿着不同的路径发展它们
当发现一个重要的错误修复，并且这在两个版本中都存在（即在 3.5 和 4.0 中），并且可以在通用代码中修复，因为 3.5 版本不会产生很多新功能，这意味着该错误很可能存在于原始版本中（在我分支之前）
因此，我创建了另一个分支，脱离原始版本（或非常接近原始版本），实施我的错误修复，然后我将此技巧合并到 3.5 和 4.0 分支中以更新它们。

我将不得不考虑这一点。似乎 Mercurial 中的合并会拉入文件，而不是更改，这意味着对需要修复错误的文件所做的任何更改都有被“合并”回早期阶段的风险，但我必须对其进行测试。

【问题讨论】：

mercurial 中的合并是关于变更集，而不是文件。 Mercurial 甚至对重命名或复制的文件应用更改（只要将副本告知 mercurial [hg cp 或 hg mv]，它不会自动跟踪移动或副本）。我接近分支点的观点是不要引入不相关的更改。还可以查看nvie.com/git-model 以了解可能的开发模型，并查看stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial 以更深入地解释 mercurial（和 git）分支。 stackoverflow.com/questions/2621610 也包含很多资源。

标签： mercurial branch class-library

【解决方案1】：

我会为不同的环境使用两个克隆（=基本上是两个匿名分支），也可能在每个克隆中使用不同的分支名称。此外，我会为每个错误修复或可互换功能使用一个新分支，从尽可能靠近分支点开始，以使主分支之间的合并更容易。我会尝试在 3.5 分支中开发错误修复，因为 4.0 树中的错误修复更有可能由于那里的其他更改而导致合并问题（我并不是说这种方法不会导致任何问题）。

【讨论】：

假设我刚刚创建了我的分支，现在两者是相同的。然后我对两者都进行了一些编辑，例如删除 3.5 版本中的一些代码和 4.0 版本中的大量代码。为了实现一个常见的错误修复，我应该创建另一个分支，靠近原始分支点（它们仍然非常相似），然后将错误修复的新分支合并到两个主要分支的尖端，是这样的你看到这个了吗？没想到……
@Lasse V. Karlsen 完全正确。要点是在合并源和合并目标之间至少存在令人不安的提交。通过这种交换，您通常无法减少合并目标端的更改集（因为它们通常应该转到提示），因此主要计划是在分支点启动它们。缺点是在这种情况下您必须进行两次合并：一次用于移植到另一个分支，但另一个在同一分支内，以便将错误修复也带到自己分支的尖端。