Mercurial：维护 Visual studio 2005 和 2008 分支
我正在尝试开发一种工作流程，使我们能够维护单独的 Visual studio 2005 和 2008 版本的库，同时确保对一个分支的更改始终复制到另一个分支中。
目前，我建议仅对默认 (VS2005) 分支进行更改，然后在完成后合并到 VS2008 分支中。不幸的是，这依赖于纪律，而不仅仅是在发现问题时解决问题，并且当您处于紧要关头时，这可能会很困难。这导致我不得不尝试稍后将一个分支的更改改回默认值。
我知道我们可以将 VS2005 和 VS2008 项目之间的更改存储在补丁队列中，但我是团队中唯一习惯使用命令行的人，我的同事更喜欢通过 Tortoise HG 完成所有操作。
因此，我依靠事后解决问题。我当前的过程涉及导出 VS2008 分支中每个变更集的补丁并将其应用到默认分支。这很耗时，但比尝试将 VS2008 分支的提示与默认提示合并，然后手动转换回 VS2005 更不容易出错。
阅读这篇文章，我尝试撤销“升级”变更集，但是生成的撤销变更集总是最终作为 VS2008 分支的新提示，而且我无法将更改合并回来，因为生成的合并最终会在VS2008 分支，即使我尝试在提交时显式关闭分支。
我尝试了多种方法，但最终总是得到一个新的 VS2008 分支提示，并且无法将更改合并回默认分支。因此，我开始认为我在这里错过了一些明显的东西。
那么，最终，当尝试维护库的两个版本时，其他人认为最佳实践是什么？您想要的两个版本之间的唯一区别是嵌入到项目和解决方案文件中的 Visual Studio 版本号？
编辑：我试图避免的问题是，如果您将 VS2005 项目添加到 VS2008 解决方案（为了更容易调试），它会自动将 VS2005 项目“升级”到 VS2008，从而导致“更改”工作副本和飞溅不必要的“转换”文件。因此，我宁愿让分支保持独立，并要求用户在克隆后的第一次更新时选择他们需要的版本，而不是人们试图将他们的“升级”提交到主线。
进一步编辑，并提供解决方案。
经过一些更混乱的处理，我找到了一种使该工作流程与标准 TortoiseHg 工具一起工作的方法，并且只需要命令行干预来进行设置。
首先，我更新回项目从 VS2005 转换为 VS2008 的变更集。我撤销了该修订，创建了撤销补丁并删除了撤销的变更集（因为它位于默认分支中）。然后我将回退补丁应用到转换变更集（使用：hg patch --no-commit patch），然后使用新的“VS2005”分支名称提交补丁。然后我合并到（未命名的）VS2005 分支的尖端。
下一步是更新到（未修改的）VS2008 分支的旧提示，进行无关紧要的更改并将其作为新的“VS2008”分支提交。然后我合并了 VS2005 提示中的更改，但是当我提交时不允许提交对 csproj 文件的更改。然后我在提交后恢复了这些文件。
最后，我更新到VS2005提示并合并到VS2008提示中。
这导致了两个技巧，除了由于 VS2005 到 VS2008 转换而产生的差异之外，两者都具有相同的代码。
新工作流程：
- 根据需要在 VS2005 或 VS2008 分支中工作。
- 在一个分支中完成更新后，更新到另一分支，合并修改分支中的更改并提交到它自己的分支。然后更新回您的首选分支。
- 如果两个分支同时发生更新，则分别执行两个分支，即。更新到 VS2005 提示并合并到 VS2008 提示中，然后更新到 VS2008 提示并合并到上一个（合并前）VS2005 提示中。
I'm trying to develop a workflow which allows us to maintain seperate Visual studio 2005 and 2008 versions of a library, while making sure that changes to one branch are always replicated in the other branch.
At the moment, I recommend that changes are only ever made to the default (VS2005) branch and then once complete, merged into the VS2008 branch. Unfortunately this relies on the discipline not to just fix problems as and when they are found and when you are in a crunch, that can be difficult. This has resulted in me having to attempt to retrofit changes from one branch back into the default at a later date.
I know that we could store the changes between the VS2005 and VS2008 project in a patch queue, but I'm the only one in my team who is comfortable with using the command line, my colleagues prefer to do everything though Tortoise HG.
As such, I rely on fixing up problems after the fact. My current procedure involves exporting patches for every changeset in the VS2008 branch and applying them to the default branch. This is time consuming, but much less error prone than trying to merge the tip of the VS2008 branch with the tip of default, and then hand converting back to VS2005 by hand.
Having read this article, I tried backing out the 'upgrade' changeset, but the resulting backout changeset always ends up as the new tip of the VS2008 branch, plus I can't then merge the changes back in, since the resulting merge ends up in the VS2008 branch, even if I attempt to explicitly close the branch on commit.
I've tried going at this in a number of ways, but I always end up with a new VS2008 branch tip and no way to merge the changes back into the default branch. As such, I'm starting to thing that I've missed something obvious here.
So, ultimately, what do other people feel is best practice when trying to maintain two versions of a library where the only difference you want between the two are Visual Studio version numbers, embedded into the project and solution files?
Edit: The problem that I'm trying to avoid is that if you add a VS2005 project to a VS2008 solution (for easier debugging) it automatically 'upgrades' the VS2005 project to VS2008, resulting in a 'changed' working copy and a spattering of unecessary 'conversion' files. So, rather than people being tempted to commit their 'upgrade' to the mainline, I prefer to keep the branches seperate and require the user to pick the version they need on the first update after the clone.
Further edit, with solution.
With some more messing about, I found a way to make this workflow work with standard TortoiseHg tools, and command line intervention only needed to set things up.
Firstly, I updated back to the changeset in which the project was converted from VS2005 to VS2008. I backed out that revision, created a patch of the backout and stripped the backed out changeset (since it was in the default branch). Then I applied the backout patch to the conversion changeset (using: hg patch --no-commit patch) and then comitted the patch with a new "VS2005" branch name. I then merged in the tip of the (unnamed) VS2005 branch.
The next step was to update to the old tip of the (unamed) VS2008 branch, make an inconsequential change and commit it as a new "VS2008" branch. I then merged in the changes from the VS2005 tip, but when I comitted did not allow the changes to the csproj files to be comitted. I then reverted these files after the commit.
Finally, I updated to the VS2005 tip and merged in the VS2008 tip.
This resulted in two tips, both with identical code, except for the differences due to the VS2005 to VS2008 conversion.
New workflow:
- Work in either VS2005 or VS2008 branch, as required.
- Once updates are done in one branch, update to the other branch, merge the changes from the modified branch in and commit to it's own branch. Then update back to your preferred branch.
- If updates occur in both branches simultaneously, do both branches seperately, i.e,. update to the VS2005 tip and merge in the VS2008 tip, then update to the VS2008 tip and merge in the previous (pre-merge) VS2005 tip.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以尝试让它消失，而不是解决问题：尝试 premake。
Premake 是预构建系统（顾名思义，如果您愿意的话，它旨在运行 pre-make 或 pre-MSBuild）。您可以使用构建在 Lua 脚本语言之上的声明性内部 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 的交叉编译。
配置语言为 非常干净且具有声明性。然而，作为构建在 Lua 之上的内部 DSL，您还可以轻松获得非常强大、美观、富有表现力（最重要的是图灵完备）脚本语言的全面支持。配置语言的结构和术语都直接基于 Visual Studio：它谈论解决方案、项目、配置 和 平台。
premake 工具本身作为单个 .exe 分发，其中包括 Lua 解释器、Lua 标准库当然还有预制脚本本身。它完全没有外部依赖关系，不写入配置文件，也不写入甚至只是读取注册表。
您所需要做的就是将 VS2008 解决方案手动转换为预制版本一次。
Instead of solving the problem you could try to make it go away: try premake.
Premake is pre-build system (as the name implies it is intended to run pre-make or pre-MSBuild if you will). You describe your project once in a declarative internal DSL built on top of the Lua scripting language and premake can automatically generate solutions and projects for VS2008, 2005, 2003 and 2002, MonoDevelop, SharpDevelop, Code::Blocks, CodeLite or a GNU Makefile for either Unix, Cygwin or MinGW. It currently supports building C++, C and C# projects, including cross-compiling for 32/64 Bit, OSX Universal Binaries, PlayStation 3 and XBox 360.
The configuration language is very clean and declarative. However, being built as an internal DSL on top of Lua, you also have the full support of a very powerful, beautiful, expressive (and most importantly Turing-complete) scripting language at your fingertips. Both the structure and the terminology of the configuration language are directly based on Visual Studio: it talks about solutions, projects, configurations and platforms.
The premake tool itself is distributed as just a single .exe which includes the Lua interpreter, Lua standard library and of course the premake script itself. It has absolutely no external dependencies, does not write a configuration file nor writes or even just reads the registry.
All you need to do is to translate the VS2008 solution into premake once by hand.
我们使用单独的解决方案和项目文件。我们复制 .sln 和 .csproj/.vcproj/.vbproj 并在记事本中编辑它们以使用新文件。添加类时，您仍然必须记住将文件添加到其他解决方案，但否则您不必记住复制修复程序。
We use separate solution and project files. We copy the .sln and .csproj/.vcproj/.vbproj and edit them in notepad to use the new files. You still have to remember to add a file to the other solution when adding classes, but otherwise you don't have to remember to copy over the fixes.
Mercurial：权威指南一书有一个 关于使用 Mercurial 补丁队列维护旧版 Linux 内核的向后移植的整章。我认为 mq 扩展 可以帮助您。
The Mercurial: The Definitive Guide book has a whole chapter on using Mercurial Patch Queues to maintain backports for older Linux kernels. I think the mq extension could help you out.
也许您不应该维护两个不同的分支，而只应该维护一个包含源代码和 Visual Studio 2005 项目文件的分支。第二个分支应该只包含 Visual Studio 2008 项目文件，而不是源代码。要编译 Visual Studio 2008 版本，请在本地驱动器上为所有源文件创建硬链接，以使它们出现在两个文件夹树中（将硬链接创建与从存储库获取最新更新的命令一起放在批处理文件中） ）。对于这种方法，您需要 NTFS 文件系统和适当的“ln”命令行工具，例如这个。
因此，您可以在任意文件夹中调试/编辑源代码，所有更改也立即显示在另一个文件夹中。
编辑：是的，我自己尝试过，它有效。我们有一个非常相似的场景，有一个 C++ 应用程序要使用 Visual Studio 2008 和较旧的 Borland 编译器进行编译。
Perhaps you should not maintain two different branches, but only one containing the source code and the Visual Studio 2005 project files. The second branch should only contain the Visual Studio 2008 project files, not the source code again. To get the Visual Studio 2008 version compiled, create hard links on your local drive for all source files to make them appear in both folder trees (put the hard link creation in a batch file together with the commands for getting the latest updates from the repository). For this approach you need NTFS file system and an appropriate "ln" command line tool, for example this one.
So you can debug/edit your source code in either folder you want, all changes immediately appear in the other folder, too.
Edit: and yes, I have tried that by myself, it works. We have a very similar scenario, having a C++ application to be compiled with Visual Studio 2008 and an older Borland compiler.
回答我自己的问题似乎有点奇怪，但如果不这样做，我就无法向 StackOverflow 表明这个问题有一个可接受的答案。
有关完整详细信息，请参阅我的问题 - 在水平线之后。
不过，我应该感谢其他人的回答。我可能仍然会发现预制的用途，并且单独的项目/解决方案文件可以在其他情况下工作。毫无疑问，有一天我自己会发现 Mercurial 队列的用途，但我怀疑我是否会让我的开发团队的其他成员使用它们。我一直不太习惯 Windows 上的硬链接，所以我可能永远不会尝试这样做，但提醒他们它们的存在是件好事。
保重&再次感谢所有花时间回复的人。
It seems a little odd to answer my own question, but without doing this I can't indicate to StackOverflow that this question has an accepted answer.
For full details, see my question - after the horizontal rule.
I should add my thanks for everyone elses answers though. I may still find a use for premake, and seperate project/solution files could work in other situations. One day I will undoubtedly find a use for Mercurial Queues myself, but I doubt I will ever get the rest of my development team to use them. I've never been comfortable with hard links on Windows, so I probably won't ever try that, but it's good to be reminded of their existance.
Take care & thanks again to everyone who took the time to respond.