Mercurial：维护 Visual Studio 2005 和 2008 分支答案

【问题标题】：Mercurial: Maintaining Visual studio 2005 and 2008 branchesMercurial：维护 Visual Studio 2005 和 2008 分支
【发布时间】：2009-12-04 14:09:48
【问题描述】：

我正在尝试开发一种工作流程，使我们能够维护单独的 Visual Studio 2005 和 2008 版本的库，同时确保对一个分支的更改始终复制到另一个分支。

目前，我建议只对默认 (VS2005) 分支进行更改，然后在完成后合并到 VS2008 分支中。不幸的是，这依赖于纪律，而不仅仅是在发现问题时以及当您处于紧缩状态时解决问题，这可能很困难。这导致我不得不在以后尝试将更改从一个分支改回默认设置。

我知道我们可以将 VS2005 和 VS2008 项目之间的更改存储在补丁队列中，但我是团队中唯一一个习惯使用命令行的人，我的同事更喜欢使用 Tortoise HG 来做所有事情.

因此，我依靠事后解决问题。我当前的过程涉及为 VS2008 分支中的每个变更集导出补丁并将它们应用到默认分支。这很耗时，但比尝试将 VS2008 分支的尖端与默认的尖端合并，然后手动转换回 VS2005 更不容易出错。

阅读this article 后，我尝试退出“升级”变更集，但最终的退出变更集总是作为 VS2008 分支的新提示而结束，而且我无法将这些更改重新合并，因为结果合并最终在 VS2008 分支中结束，即使我尝试在提交时显式关闭分支。

我已经尝试了多种方法，但我总是得到一个新的 VS2008 分支提示，并且无法将更改合并回默认分支。因此，我开始意识到我在这里遗漏了一些明显的东西。

那么，最终，当尝试维护一个库的两个版本时，您希望两者之间的唯一区别是嵌入到项目和解决方案文件中的 Visual Studio 版本号时，其他人认为最佳实践是什么？

编辑：我要避免的问题是，如果您将 VS2005 项目添加到 VS2008 解决方案（以便于调试），它会自动将 VS2005 项目“升级”到 VS2008，从而产生“更改”的工作副本以及大量不必要的“转换”文件。因此，与其试图将他们的“升级”提交到主线，我更愿意将分支分开，并要求用户在克隆后的第一次更新时选择他们需要的版本。

进一步编辑，有解决方案。

有了更多的麻烦，我找到了一种使用标准 TortoiseHg 工具使此工作流程工作的方法，并且只需要进行命令行干预即可进行设置。

首先，我更新回了项目从 VS2005 转换为 VS2008 的变更集。我撤销了那个修订，创建了一个撤销补丁并剥离了撤销的变更集（因为它在默认分支中）。然后我将回退补丁应用于转换变更集（使用：hg patch --no-commit patch），然后使用新的“VS2005”分支名称提交补丁。然后我在（未命名的）VS2005 分支的尖端合并。

下一步是更新到（未命名的）VS2008 分支的旧提示，进行无关紧要的更改并将其提交为新的“VS2008”分支。然后我合并了来自 VS2005 提示的更改，但是当我提交时不允许提交对 csproj 文件的更改。然后我在提交后恢复了这些文件。

最后，我更新到了VS2005的tip，并合并到了VS2008的tip中。

这导致了两个提示，除了由于 VS2005 到 VS2008 的转换而导致的差异之外，它们都具有相同的代码。

新的工作流程：

根据需要在 VS2005 或 VS2008 分支中工作。
在一个分支中完成更新后，更新到另一个分支，合并来自已修改分支的更改并提交到它自己的分支。然后更新回您的首选分支。
如果两个分支同时发生更新，则分别执行两个分支，即更新到 VS2005 提示并合并到 VS2008 提示中，然后更新到 VS2008 提示并合并到上一个（合并前）VS2005 提示中。

【问题讨论】：

当您说两个版本（2005 和 2008）时，仅仅是 VS 解决方案还是代码包含特定位？
这个想法是不应该有实际的代码更改。

标签： visual-studio-2008 visual-studio-2005 mercurial tortoisehg

【解决方案1】：

您可以尝试使其消失，而不是解决问题：尝试premake。

Premake 是预构建系统（顾名思义，如果您愿意，它旨在运行 pre-make 或 pre-MSBuild）。您在Lua scripting language 之上构建的声明性内部 DSL 中描述您的项目一次，premake 可以自动为 VS2008、2005、2003 和 2002、MonoDevelop、SharpDevelop、Code::Blocks 生成解决方案和项目, CodeLite 或适用于 Unix、Cygwin 或 MinGW 的 GNU Makefile。它目前支持构建 C++、C 和 C# 项目，包括针对 32/64 位、OSX 通用二进制文件、PlayStation 3 和 XBox 360 的交叉编译。

配置语言为very clean and declarative。但是，作为在 Lua 之上构建的内部 DSL，您还可以轻松获得对非常强大、美观、富有表现力（最重要的是图灵完备）脚本语言的全面支持。配置语言的结构和术语都直接基于Visual Studio：它谈到solutions, projects、configurations和platforms。

premake 工具本身是distributed as just a single .exe，它包括 Lua 解释器、Lua 标准库，当然还有 premake 脚本本身。它绝对没有外部依赖，不写配置文件，也不写甚至只是读注册表。

您需要做的就是将VS2008解决方案手动翻译成premake 一次。

【讨论】：

这看起来不错，但它似乎缺少一些功能，并且 5 月的补丁还没有被引入到构建中。它看起来已经停滞不前了。
最后一次提交到源代码存储库是 46 小时前，即将发布的 4.2 版本的 beta 版本（添加对 XCode IDE 的支持并构建 Objective-C 和 Objective-C++）是 20 和 25几天前，当前稳定的 4.1 版本的三个版本（到目前为止）分别是 3 个月、5 个月和 6 个月前，上次有人在论坛上提问是在两周前，作者本人在几分钟内做出了回应。作者在论坛上的最后一个帖子是昨天。所以，在我看来，它并没有停滞不前。
如果有人在寻找 Premake 信息时发现了这个线程：我们推迟了这些补丁，因为它们很大并且需要额外的工作，而 Xcode 支持不得不退出。我认为我们的整体业绩记录非常好。不过没有冒犯，只是想清除记录。

【解决方案2】：

我们使用单独的解决方案和项目文件。我们复制 .sln 和 .csproj/.vcproj/.vbproj 并在记事本中编辑它们以使用新文件。添加类时，您仍然必须记住将文件添加到其他解决方案中，否则您不必记住复制修复。

【讨论】：

【解决方案3】：

Mercurial: The Definitive Guide 书中有一个whole chapter 介绍了使用 Mercurial Patch Queues 来维护旧 Linux 内核的反向移植。我认为mq extension 可以帮助您。

【讨论】：

正如我所说，虽然我很乐意自己使用 MQ，但说服我的团队的其他成员使用它们会很棘手。如果我不能让他们遵循“只在默认情况下修复，然后合并到 VS2008”的过程，我看不出如何让他们接受推拉补丁队列的麻烦。我真正需要的是一种更简单的方法来解决问题（忘记程序）。

【解决方案4】：

也许您不应该维护两个不同的分支，而应该只维护一个包含源代码和 Visual Studio 2005 项目文件的分支。第二个分支应该只包含 Visual Studio 2008 项目文件，而不是源代码。要编译 Visual Studio 2008 版本，请在本地驱动器上为所有源文件创建硬链接，以使它们出现在两个文件夹树中（将硬链接创建与从存储库获取最新更新的命令一起放在批处理文件中)。对于这种方法，您需要 NTFS 文件系统和适当的“ln”命令行工具，例如 this one。

因此您可以在所需的任一文件夹中调试/编辑源代码，所有更改也会立即显示在另一个文件夹中。

编辑：是的，我自己尝试过，它有效。我们有一个非常相似的场景，需要使用 Visual Studio 2008 和旧版 Borland 编译器编译 C++ 应用程序。

【讨论】：

【解决方案5】：

回答我自己的问题似乎有点奇怪，但如果不这样做，我无法向 StackOverflow 表明这个问题有一个可接受的答案。

有关详细信息，请参阅我的问题 - 在水平线之后。

不过，我应该感谢其他所有人的回答。我可能仍然会发现 premake 的用途，并且单独的项目/解决方案文件可以在其他情况下工作。有一天，我自己无疑会发现 Mercurial Queues 的用途，但我怀疑我是否会让我的开发团队的其他成员使用它们。我从来不习惯在 Windows 上使用硬链接，所以我可能永远不会尝试这样做，但提醒一下它们的存在是件好事。

请注意并再次感谢所有花时间回复的人。

【讨论】：