我们正在考虑在我们的工作场所从SVN转换到分布式版本控制系统(DVCS)。
我很熟悉为什么想要在日常开发中使用DVCS的所有原因:本地版本控制,更容易的分支和合并等等,但是我还没有看到太多关于管理软件发布方面的有说服力的东西。以下是我们的发布流程:
- 发现可用于合并的变更。 - 运行查询以查找与这些变更相关联的缺陷/票证。 - 过滤与“打开”票证相关联的变更。在我们的环境中,必须关闭票证才能将其与发布分支合并。 - 过滤我们不希望出现在发布分支中的变更。当涉及到合并变更时,我们非常保守。如果一个变更不是绝对必要的,就不会被合并。 - 合并可用的变更,最好按时间顺序。如果它们与同一票证相关联,我们会将变更组合在一起。 - 阻止不需要的变更进入发布分支(
有时我们可能同时处理3-5个不同的里程碑。某些里程碑的约束条件非常不同,而屏蔽列表可能会变得相当长。
我已经在使用Git、Mercurial和Plastic,据我所知,它们都没有很好地解决这个模型。当你只发布一个产品时,它们似乎能很好地工作,但是我无法想象如何在同一代码库中处理多个非常不同的产品。
例如,在Mercurial中,挑选变更似乎是一个事后的想法。(您必须使用“移植”扩展,它默认处于禁用状态)。在将变更挑选到分支之后,它仍然显示为可用的集成。挑选变更会破坏Mercurial的工作方式。
DVCS似乎更适合特性分支。如果您直接从特性分支合并到主干和发布分支,则不需要挑选变更。但是,谁愿意一直进行所有这些合并呢?如何查询可用于合并的内容?如何确保特性分支中的所有更改都属于一起?这听起来像是完全混乱的。
我感到纠结,因为作为程序员,我希望在日常工作中使用DVCS。我真的很想要它。但是,我担心有一天我不得不戴上发布管理者的帽子,整理出需要合并和不需要合并的内容。我想写代码,我不想成为合并机器。
我很熟悉为什么想要在日常开发中使用DVCS的所有原因:本地版本控制,更容易的分支和合并等等,但是我还没有看到太多关于管理软件发布方面的有说服力的东西。以下是我们的发布流程:
- 发现可用于合并的变更。 - 运行查询以查找与这些变更相关联的缺陷/票证。 - 过滤与“打开”票证相关联的变更。在我们的环境中,必须关闭票证才能将其与发布分支合并。 - 过滤我们不希望出现在发布分支中的变更。当涉及到合并变更时,我们非常保守。如果一个变更不是绝对必要的,就不会被合并。 - 合并可用的变更,最好按时间顺序。如果它们与同一票证相关联,我们会将变更组合在一起。 - 阻止不需要的变更进入发布分支(
svnmerge block
),以便我们不必再次处理它们。有时我们可能同时处理3-5个不同的里程碑。某些里程碑的约束条件非常不同,而屏蔽列表可能会变得相当长。
我已经在使用Git、Mercurial和Plastic,据我所知,它们都没有很好地解决这个模型。当你只发布一个产品时,它们似乎能很好地工作,但是我无法想象如何在同一代码库中处理多个非常不同的产品。
例如,在Mercurial中,挑选变更似乎是一个事后的想法。(您必须使用“移植”扩展,它默认处于禁用状态)。在将变更挑选到分支之后,它仍然显示为可用的集成。挑选变更会破坏Mercurial的工作方式。
DVCS似乎更适合特性分支。如果您直接从特性分支合并到主干和发布分支,则不需要挑选变更。但是,谁愿意一直进行所有这些合并呢?如何查询可用于合并的内容?如何确保特性分支中的所有更改都属于一起?这听起来像是完全混乱的。
我感到纠结,因为作为程序员,我希望在日常工作中使用DVCS。我真的很想要它。但是,我担心有一天我不得不戴上发布管理者的帽子,整理出需要合并和不需要合并的内容。我想写代码,我不想成为合并机器。