Mercurial:.NET 3.5 和 4.0 都将存在的类库？

Question

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

在那个过程中，我会剔除很多旧的垃圾，并重写一些代码以更好地利用 .NET 4.0 中的新类和支持(如 TPL)。类库因此会有所不同，但仍然是足够相似以至于可以以相同的方式对两者进行一些错误修复。

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

我在想:

1. 在一个存储库中命名分支，然后可以将任何错误修复从一个存储库移植到另一个存储库
2. 一个版本库中未命名的分支，也可以移植，但我觉得这样看起来会很乱
3. 单独的存储库，将不得不重新实现错误修复(或使用非 Mercurial 集成的比较工具来帮助我)

你会怎么做？ (也欢迎我没有想到的任何其他替代方案。)

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

---

编辑 来自 @Rudi的回答here ，我认为他的意思是这样的:

1. 创建两个分支(或保留一个“默认”并为另一个路径创建另一个分支，在我的例子中是“default”=.NET 4.0，“net35”=.NET 3.5)
2. 沿着不同的路径发展他们
3. 当发现一个关键错误修复时，它存在于两个版本中(即在 3.5 和 4.0 中)，并且可以在通用代码中修复，因为 3.5 版本不会产生很多新功能，这意味着该错误很可能存在于原始版本中(在我分支之前)
4. 因此，我创建了另一个分支，脱离原始版本(或非常接近原始版本)，实现我的错误修复，然后我将此技巧 merge 到 3.5 和 4.0 分支中以更新它们。

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

Answer 1

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