3

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

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

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

我在想：

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

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

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

从@Rudi在这里的回答中编辑，我认为他的意思是：

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

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

4

1 回答 1

3

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

于 2010-05-20T13:19:29.553 回答