我正在尝试开发一个工作流程，它允许我们维护独立的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提示，并在VS2008提示中合并。
除了VS2005到VS2008转换的差异外，这两个提示都有相同的代码。
新工作流程：
答案 0 :(得分：2)
不是解决问题，而是试图让它消失：尝试premake。
Premake是预构建系统（顾名思义，如果你愿意，它可以运行pre-make或pre-MSBuild）。您在构建于Lua scripting language之上的声明性内部DSL中描述您的项目一次，并且premake可以自动为VS2008,2005,2003和2002生成解决方案和项目，MonoDevelop，SharpDevelop，代码： ：用于Unix，Cygwin或MinGW的Blocks，CodeLite或GNU Makefile。它目前支持构建C ++，C和C＃项目，包括32/64 Bit，OSX Universal Binaries，PlayStation 3和XBox 360的交叉编译。
配置语言为very clean and declarative。然而，作为Lua之上的内部DSL构建，您还可以获得一个非常强大，美观，富有表现力（最重要的图灵完整）脚本语言的全面支持。配置语言的结构和术语都直接基于Visual Studio：它讨论solutions, projects，configurations和platforms。
预制工具本身是distributed as just a single .exe，其中包括Lua解释器，Lua标准库以及预制脚本本身。它绝对没有外部依赖，不写配置文件，也不写，甚至只是读取注册表。
您需要做的就是手动将VS2008解决方案翻译成premake 。
答案 1 :(得分：1)
我们使用单独的解决方案和项目文件。我们复制.sln和.csproj / .vcproj / .vbproj并在记事本中编辑它们以使用新文件。在添加类时，您仍然需要记住将文件添加到其他解决方案，否则您不必记住复制修复。
答案 2 :(得分：1)
Mercurial: The Definitive Guide本书有whole chapter使用Mercurial Patch Queues来维护旧版Linux内核的后端端口。我认为mq extension可以帮助你。
答案 3 :(得分：0)
也许你不应该维护两个不同的分支，但只有一个包含源代码和Visual Studio 2005项目文件。第二个分支应该只包含Visual Studio 2008项目文件，而不是源代码。要编译Visual Studio 2008版本，请在本地驱动器上为所有源文件创建硬链接，以使它们出现在两个文件夹树中（将硬链接创建与批处理文件一起，以及从存储库获取最新更新的命令） ）。对于这种方法，您需要NTFS文件系统和适当的“ln”命令行工具，例如this one。
因此，您可以在所需的任一文件夹中调试/编辑源代码，所有更改也会立即显示在另一个文件夹中。
编辑：是的，我自己试过，它有效。我们有一个非常类似的场景，有一个C ++应用程序可以使用Visual Studio 2008和较旧的Borland编译器进行编译。
答案 4 :(得分：0)
回答我自己的问题似乎有点奇怪，但如果不这样做，我就无法向StackOverflow表明这个问题已经接受了答案。
有关详细信息，请参阅我的问题 - 在水平规则之后。
我应该感谢所有人的回答。我仍然可以找到预制的用途，单独的项目/解决方案文件可以在其他情况下使用。有一天，我自己会毫无疑问地找到Mercurial Queues的用途，但我怀疑我是否会让其余的开发团队使用它们。我从来没有对Windows上的硬链接感到满意，所以我可能永远不会尝试，但最好提醒他们存在。
保重＆amp;再次感谢所有花时间回应的人。