Mercurial:维护Visual Studio 2005和2008分支

我正在尝试开发一个工作流,它允许我们维护一个库的单独的Visual Studio 2005和2008版本,同时确保对一个分支的更改总是在另一个分支中复制。

目前,我建议只对默认(vs2005)分支进行更改,然后在完成后合并到vs2008分支。不幸的是,这取决于纪律,而不仅仅是在发现问题时解决问题,当你陷入困境时,解决问题可能会很困难。这导致我不得不尝试在以后将一个分支的更改修改为默认更改。

我知道我们可以将VS2005和VS2008项目之间的更改存储在一个补丁队列中,但我是团队中唯一一个对命令行的使用感到满意的人,我的同事更喜欢通过tortoise hg来做任何事情。

因此,我依赖于事后解决问题。我当前的过程涉及导出VS2008分支中每个变更集的修补程序,并将它们应用到默认分支。这很耗时,但比尝试将VS2008分支的提示与默认提示合并,然后手动转换回VS2005要容易出错得多。

读过 this article ,我尝试退出“upgrade”变更集,但结果的back out变更集始终作为vs2008分支的新提示结束,而且我无法再将更改合并回中,因为结果的合并最终在vs2008分支中结束,即使我尝试在提交时显式关闭分支。

我已经尝试了很多方法,但最终总是得到一个新的VS2008分支提示,并且没有办法将更改合并回默认分支。因此,我开始意识到我错过了一些显而易见的事情。

因此,最终,当试图维护库的两个版本时,其他人认为最佳实践是什么,在这两个版本之间,您想要的唯一区别是嵌入到项目和解决方案文件中的Visual Studio版本号?

编辑:我试图避免的问题是,如果您将VS2005项目添加到VS2008解决方案中(为了更容易调试),它会自动将VS2005项目“升级”到VS2008,从而导致“更改”工作副本和大量不必要的“转换”文件。因此,我不想让人们将他们的“升级”提交到主线,而是希望将分支分开,并要求用户在克隆之后的第一次更新时选择他们需要的版本。

用解决方案进一步编辑。

更麻烦的是,我找到了一种方法让这个工作流与标准的TortoiseHg工具一起工作,而命令行干预只需要设置一些东西。

首先,我更新回项目从VS2005转换到VS2008的变更集。我撤销了修订,创建了一个backout补丁,并去掉了backout变更集(因为它在默认分支中)。然后,我将backout补丁应用到转换变更集(使用:hg patch--no commit patch),然后用一个新的“vs2005”分支名称组合补丁。然后我合并到(未命名的)VS2005分支的尖端。

下一步是更新(unamed)vs2008分支的旧提示,进行无关紧要的更改,并将其作为新的“vs2008”分支提交。然后,我合并了VS2005提示中的更改,但当我提交时,不允许提交对csproj文件的更改。然后我在提交之后恢复了这些文件。

最后,我更新了VS2005技巧,并合并到了VS2008技巧中。

这导致了两个提示,两个提示的代码相同,但由于VS2005到VS2008转换而产生的差异除外。

新的工作流程:

• 按要求在VS2005或VS2008分公司工作。
• 在一个分支中完成更新后,更新到另一个分支,将修改后的分支的更改合并到中,并提交到它自己的分支。然后更新回您的首选分支。
• 如果两个分支中同时发生更新,请分别执行两个分支,即。更新到vs2005 tip并在vs2008 tip中合并,然后更新到vs2008 tip并在上一个(预合并)vs2005 tip中合并。