重构和并发开发分支

我认为将适当的更改合并到主干的当前状态是分支维护开发人员的责任。有几种可能性:

1. 后备箱中的代码没有更改,补丁应用时没有冲突。
2. 后备箱中的代码已经更改并应用了补丁,但需要手动合并。
3. 后备箱中的代码已完全更改,无法应用修补程序。开发人员必须评估主干中是否存在相同的缺陷,并在需要时应用同等的修复方法。

案例1和案例2是常见的维护开发路径。案例3是您正在考虑的案例,其中主干代码不能接受任何形式的维护补丁。如果开发人员自己无法确定主干中是否存在相同的问题,那么他应该将问题输入问题跟踪系统。这个问题将指导主干开发人员考虑维护分支中补丁的原因以及相同的缺陷是否仍然存在。为输入新问题 可能的 主干中的缺陷应该是维护开发人员的最后手段。

让维护开发人员尝试对更新后的主干应用补丁的一个好处是增加他们对新代码库的熟悉度。最终,它们将耗尽维护工作,需要使用新的主干。至少有一个基本的熟悉程度将是非常有益的。

这最终是一个关于团队沟通的问题,而不是一个简单的分支/合并问题。

第一步,和所有这些情况一样,是认识到你有问题。这是你所做的。

然后,您需要提醒整个团队注意这个问题。

一旦你这样做了,我认为有两种不同的途径:

1. 如果维护分支很少使用,比如说发布的代码相当成熟并且没有错误,那么您可以决定代码冻结。每个开发人员必须在10月32日前完成他/她正在进行的工作,并将这些更改合并回主干中。然后,应关闭或冻结分支。然后,工作可以继续在后备箱,新的软件可以被释放。

2. 如果在分支机构中有频繁或紧急的变更和修复,那么这个问题就更加复杂了。代码仍然需要冻结,否则主干将被多次删除。但在这里,开发人员仍然需要在过渡期内解决问题,并把它们交给客户。我建议在主干代码冻结之后,分支中的每一个更改都应该记录在bug跟踪数据库中(在每种情况下都必须这样做),并有一个特别的指示,表明分支n中已经修复了这个问题,但还没有合并到主干中。这需要仔细记录,以便记住所有相关的细节。

   在重构主干之后,但在清理、抛光、标记和释放主干之前,请查看bug数据库,尤其是在分支中修复的项目,而不是主干。它们仍然相关吗?如果需要,现在是再次更改代码的时候了。这可能意味着短时间内要加倍工作,但希望代码现在更易于维护。

   一旦所有已知问题都得到修复,就可以发布新版本,并关闭旧分支。

我能想到的唯一答案是在您开始重构之前创建一个维护主干分支。您维护这个新的分支,就像它是一个主干一样,像往常一样合并对发布分支的更改。接下来,您必须小心混合来自新旧源库的更改。

另一种选择是尝试 MolhadoRef ( blog article about MolhadoRef and Refactoring-aware SCM ,如果您可以找到满足您需求的现成生产等效系统。理论上,这是重构感知的源代码管理。我已经有一段时间没有研究过它了,但我记得,它还远不止是一篇研究论文和概念证明。

实际上,您可能需要做额外的工作来使新的更改向后兼容。

• 步骤1:开始重构组件。在每一步中,保留旧的接口,但让它将调用迁移到新的实现中。请注意,在构建新的接口/API时,这可以通过几个步骤来完成。单元测试 应该 能够验证从旧的迁移到新的迁移是否正确工作,但是这个步骤很可能仍然会导致测试/QA开销。

• 第二步:新版本正在生产中;确保每个人都知道它。此时,不会向旧版本添加新功能,所有新的(或更改的)调用者都使用新版本。

• 步骤3:找到调用旧接口的所有内容(使用工具执行此操作),然后更改所有内容以调用新接口。这也可能导致大量的测试/QA开销。但是,每个调用者可以一次提交/释放一个。

• 步骤4:此时,新版本是实时的,并且没有留下访问旧版本的呼叫者。安全删除。

请注意,如果API是公开的,并且您不控制调用它的人员(例如,微软这样的公司),那么您可能永远无法越过步骤2。

这个过程可能很慢,而且需要大量的规程、通信和测试。但是,如果替代方案永远在追赶/整合,这可能是一个合理的选择。

考虑到修复一个bug的很多成本都是在复制问题并测试修复。您是否可以编写一个在所有分支中都可以工作的自动化测试,即使每个分支的代码修复必须不同地进行?

当您的维护分支不再与主干兼容时,是时候为此目的创建新的分支了。也就是说,在大项目开始时,您要确保您的所有开发人员都知道主干中有新的功能,这样他们就可以更好地选择在哪里实现修复。假定,如果主主干中发生的代码更改如此重要,以致于维护不可支持,那么应该将维护合并到主主干中。

创建一个维护分支,并让它作为主干和版本分支之间的缓冲区。

对版本分支的更改进入维护分支,然后只有在可以时才进入主干,反之亦然。

不过,我认为没有银弹。随着分支越来越分散,它们将变得不兼容,因此您必须考虑支持它们的时间。否则,您可能会不止一次地修复bug,但对于不同的分支来说,情况略有不同。

这可能是一个非常工作密集的建议,但我首先想到的是将所有东西合并回主干。每个人的更改都被合并回主干副本,并将它们放在一起。然后,根据需要在主干上重构。现在你有了一个可以工作的后备箱,所有的修复都放在一起了。

不幸的是,这意味着维护分支中的任何修复程序都需要放到一起并放到中央主干中。我意识到这将是一个很大的工作,但我认为这将允许重构所有东西,并且维护分支的任何改进都将属于主分支。我可能很幼稚,但我还没有真正从事过生产项目,也不知道维护部门到底在做什么。我认为这将使主干完全更新,您所有的维护改进将集成到主干中。

我认为这样做可以最大限度地提高所有分支的质量,并使重构分布在重构之后要分支的所有分支上。这将是一个很好的方法,使您的团队在所有的合并中,以及。

我看到两种不同的方法来解决这个问题:

1。

不应该在主干中对主干进行重大更改(如重大重构)。它们应该在一个分支中完成,并在足够稳定的时候重新合并到主干中。

对主干的更改应定期与其他维护分支合并。当重构稳定时,只将其合并到主干中的原因是,这些重构随后将被合并到维护分支中。但是,如果没有机会使这些变化保持稳定,那么选项2会更好。

在对维护分支进行更改之后,可以将它们合并回主干中。

2。

创建维护分支的分支(每个分支对应一个分支)。这将用于将主干与每个维护分支合并。(请注意,为了限制维护分支的数量,应使用SVN Externals或等效工具)。

在主干中进行所有重构,并将其合并到维护分支的分支中。当您释放或认为主干是稳定的时,那么将维护释放的这些分支合并回它们各自的分支。然后这些可以依次合并到主干中。

实际上,每个维护分支都变成了“子主干”。

请注意,此场景强调了未来维护和前期维护之间的权衡。代码中的分支和差异越多,就需要进行更多的前期维护。好的方面是增量维护要容易得多。

我只能重复别人说的话,同时强调补丁队列中的A$真正的痛苦。

如果你有一个预先定义的(铁壳的)合并窗口,你应该只有两个星期的地狱来处理。

我认为你最好的选择是 迭代的 重构。不要在一个私有分支上一次性完成所有重构,而是一个阶段一次完成。在分支上进行几组更改,然后当您知道它们是稳定的时,将它们合并到主干上。在其他分支上工作的开发人员将负责不断地使其分支与主干保持最新。

合并一组很小的更改通常比合并差异很大的大型分支要少得多。合并的频率越高,最终需要做的工作就越少。

在我们的项目中,我们主要不修复版本维护分支中的更改。如果有虫子和

1. 它同时发生在主干和主分支中,我们将它固定在主干中,然后将更改合并到维护分支(这可能会很干净地发生,或者需要更多的工作,在这种情况下,我们决定是否最好只在更新的版本中修复这个bug)。
2. 它只在维修部门,可能在后备箱里有一个修理之王,我们去气味一号。

你必须 有 很多分支机构都在工作?

主干上的工作仅仅是在项目计划说当前版本已经准备好装运时才开始的,因此它已经装运了吗?

因为客户出于某种原因拒绝升级到最新版本,您有很多维护分支吗?如果是这样,说明原因。

您是否有太多的旧版本,因为在下一个主版本之前,差距太大?

你是否向那些不愿意升级的客户收取更多的维护费用,因为这会让你付出更多的代价?

评论回复:

微软仍然支持Windows XP 即使Vista不在

是非常正确的,但是微软仍然不支持windowsxpsp1,即使xp sp3不在。

这不是黑白的,即使您不能停止支持旧版本,您也可以减少支持的旧版本的数量。问题是,销售/支持人员喜欢说“是”,但开发会带来痛苦,因此您需要让销售/支持人员站在一边。

AS Greg pointed 有几种可能的情况。

我会添加一个案例(2.5),其中需要手动合并,但是由于您已经将一个方法从其原始位置移开,然后应用了一些更改,所以很难合并,特别是如果“维护”分支中的“基础”代码也被修改了。这并不像听起来那么罕见,事实上,将一个方法移动到不同的位置并应用一个小的修复是非常常见的。

我们开发了一个名为xmerge(交叉合并)的工具,这是实现重构感知合并的第一步。它还不是自动的,但它有助于处理涉及移动代码的艰难合并。 It's described here 并已集成在塑料单片机2.7中。

我们正在研究:自动移动检测,还能够“交叉合并”多个目标文件(您将代码移动到另一个文件,这也是非常常见的)。