Mercurial：.NET 3.5 和 4.0 都存在的类库？
我有一个用 .NET 3.5 编写的相当大的类库，我想升级它以使其也可用于 .NET 4.0。
在此过程中，我将剔除大量旧垃圾，并重写一些代码，以更好地利用 .NET 4.0 中的新类和支持（如 TPL）。因此，类库将有所不同，但仍然足够相似，以至于可以用相同的方式对两者进行一些错误修复。
我应该如何在 Mercurial 中最好地组织这个类库？如果重要的话，我正在使用 Kiln (fogbugz)。
我在想：
- 一个存储库中的命名分支，然后可以将任何错误修复从一个存储库移植到另一个
- 存储库中的未命名分支，也可以移植，但我认为这会看起来很混乱
- 单独的存储库，将不得不重新实现错误修复（或使用一个非 Mercurial 集成的比较工具来帮助我）
你会做什么？ （也欢迎我没有想到的任何其他替代方案。）
请注意，类库在某些领域会有很大分歧，我有一些旧集合类型代码的残余，它们执行与 Linq 类似的操作，我将删除它们，以及一些使用它的代码，我将重写它们以使用 Linq 方法。因此，仅复制项目文件并使用 #if NET40..#endif 部分是行不通的。此外，类库的 3.5 版本不会获得许多新功能，大部分只是关键的错误修复，因此保持两个版本同样“活跃”并不是真正必要的。因此，所有文件的单独副本就足够了。
- 两个分支（或保留一个“默认”分支并为另一条路径创建另一个分支，在我的情况下为“default”=.NET 4.0，“net35”=.NET 3.5）
- 沿着不同的路径开发它们
- 当发现关键错误修复，并且这两个版本（即 3.5 和 4.0 中）都存在，并且可以在通用代码中修复时，因为 3.5 版本不会产生很多新功能，这意味着该错误已被修复最有可能存在于原始版本中（在我分支之前），
- 因此我创建了另一个分支，脱离原始版本（或非常接近它），实现我的错误修复，然后我将这个技巧合并到 3.5 和 4.0 分支中更新它们。
我得考虑一下这个问题。 Mercurial 中的合并似乎会拉入文件，而不是更改，这意味着对需要修复错误的文件所做的任何更改都有被“合并”回早期阶段的风险，但我必须对其进行测试。
I have a rather big class library written in .NET 3.5 that I'd like to upgrade to make available for .NET 4.0 as well.
In that process, I will rip out a lot of old junk, and rewrite some code to better take advantage of the new classes and support in .NET 4.0 (like TPL.) The class libraries will thus diverge, but still be similar enough that some bug-fixes can be done to both in the same manner.
How should I best organize this class library in Mercurial? I'm using Kiln (fogbugz) if that matters.
I'm thinking:
- Named branches in one repository, can then transplant any bugfixes from one to the other
- Unnamed branches in one repository, can also transplant, but I think this will look messy
- Separate repositories, will have to reimplement the bugfixes (or use a non-mercurial-integraded compare tool to help me)
What would you do? (any other alternatives that I haven't though of is welcome as well.)
Note that the class libraries will diverge pretty heavily in areas, I have some remnants of old collection-type code that does something similar to Linq that I will remove, and some code that uses it that I will rewrite to use the Linq-methods instead. As such, just copying the project files and using #if NET40..#endif sections is not going to work out. Also, the 3.5 version of the class library will not be getting many new features, mostly just critical bug-fixes, so keeping both versions equally "alive" isn't really necessary. Thus, separate copies of all the files are good enough.
Edit From @Rudi's answer here, I think what he's saying is this:
- Create two branches (or keep one "default" and create another branch for the other path, which would be "default"=.NET 4.0, and "net35"=.NET 3.5 in my case)
- Develop them along their diverging paths
- When a critical bugfix is found, and this exists in both versions (ie. in both 3.5 and 4.0), and can be fixed in common code, since the 3.5 version won't accrue a lot of new functionality, it means the bug was most likely present in the original version (before I branched)
- I thus create another branch, off of the original version (or very close to it), implement my bugfix, and then I merge this tip into both the 3.5 and the 4.0 branches to update them both.
I will have to think about this. It seems merging in Mercurial pulls in the files, not the changes, which means any changes done to the files that needs to be bugfixed, risks being "merged" back to an earlier stage, but I'll have to test it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会为不同的环境使用两个克隆（=基本上是两个匿名分支），也许每个克隆中也有不同的分支名称。此外，我会为每个错误修复或可互换功能使用一个新分支，从尽可能靠近分支点开始，以使主分支之间的合并更容易。我会尝试在 3.5 分支中开发错误修复，因为 4.0 树中的错误修复更有可能由于那里的其他更改而导致合并问题（我并不是说这种方法不会导致任何问题）。
I would use two clones for the different environments (=basically two anonymous branches), maybe also with different branch names within each clone. Also I would use a new branch for each bug fix or interchangeable feature, starting as nearest to the branch point as possible, to make merges between the main branches easier. I would try to develop the bug fixes in the 3.5 branch, since it is more likely that bug fixes in the 4.0 tree would cause merge problems due to other changes there (I'm not saying that this approach does not cause any problems).