我正在尝试开发一个工作流，它允许我们维护单独的 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的tip，并合并到了VS2008的tip中。
这导致了两个提示，除了由于 VS2005 到 VS2008 的转换而导致的差异之外，它们都具有相同的代码。
新工作流程：
- 根据需要在 VS2005 或 VS2008 分支中工作。
- 在一个分支中完成更新后，更新到另一个分支，合并来自已修改分支的更改并提交到它自己的分支。然后更新回您的首选分支。
- 如果两个分支同时发生更新，则分别执行两个分支，即。更新到 VS2005 提示并合并到 VS2008 提示中，然后更新到 VS2008 提示并合并到上一个（合并前）VS2005 提示中。