颠覆、融合

发布于 2024-11-14 10:05:24 字数 560 浏览 6 评论 0原文

首先,我先说一下,我以前在这里问过类似的问题,但从未得到一个很好的答案来解决我缺乏知识/问题。

首先,让我从分支战略提案开始。这就是我们的工作,我很高兴听到其他评论,以及为什么这很糟糕。但要明白,它通常对我们有用。

我们有 1 个产品。为了这个示例,我们将其称为“产品”。我们运行 2 个并发开发周期。每周维护周期,我们修复非紧迫的错误,以及每两周一次的冲刺。从主干创建了 2 个分支,分别称为“Sprint”和“Maintenance”(我知道这个名字的选择令人震惊!)。此外,对于紧急/阻塞问题,修复会直接在主干中进行,并在测试后推送到生产中。

当我尝试将冲刺或维护重新集成回主干时,十有八九会遇到大量冲突。甚至从未在其中一个分支中处理过的文件。这会导致大量的手动合并,这很糟糕,而且往往会导致更多问题。

所以我将发出命令: svn merge --reintegrate http://repo/Sprint 虽然某些文件会更新,但完全相同的文件(通过 WinMerge)会发生冲突。我不知道是什么原因导致了这些冲突。

我怎样才能停止这些荒谬的冲突呢?

First let me preface by saying, I've asked similar questions here before, and never gotten a good answer that solved my lack of knowledge/problem.

First, let me start this off with a branching strategy proposal. This is what we have at work, and I'm happy to hear comments otherwise, and as to why this sucks. But understand that it generally works for us.

We have 1 product. For the sake of this example, lets call it "PRODUCT". We run 2 concurrent development cycles. A weekly maintenance cycle, where we fix non-pressing bugs, and a bi-weekly sprint. There are 2 branches created from trunk called "Sprint" and "Maintenance"(shocking name choice I know!). Also for urgent/blocker issues, fixes are made directly into trunk and pushed to production after testing.

9 times out of 10 when I try to reintegrate the sprint or maintenance back into the trunk I get LARGE amounts of conflicts. On files that were never even worked on in one of the branches. This then leads to lots of manual merging, which sucks, and tends to lead to more problems.

So I will issue command: svn merge --reintegrate http://repo/Sprint
and while some files will update, I will have conflicts on files that are EXACTLY identical(via WinMerge). I don't know what causes these conflicts.

How can I stop having these ridiculous conflicts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

怎言笑 2024-11-21 10:05:24

一种答案是使用许多小的特征分支,而不是两个固定分支。您的问题是,固定分支的更改被合并,然后您对固定分支进行了更多更改,这些更改似乎与第一次合并冲突,即使它们实际上没有冲突。

因此,要么使用许多小的功能分支,要么切换到像 Mercurial 或 git 这样的 DVCS,它们以比 SVN 目前更智能的方式处理合并。

One answer is to use many small feature branches, not two fixed branches. Your problem is that changes from your fixed branches get merged, and then you do some more changes on the fixed branches and those changes appear to conflict with the first merge, even when they really don't.

So either use many small feature branches, or switch to a DVCS like Mercurial or git which handles merging in a more intelligent way than SVN currently does.

嘴硬脾气大 2024-11-21 10:05:24

您可能会发现 Timpani Software 的 MergeMagician 项目很有趣。它是一个分支管理和自动合并解决方案,可与 Subversion(以及 Microsoft TFS)配合使用。您在分支之间创建发布/订阅关系,然后服务器自动进行合并。

MM 促进的频繁合并将减少合并冲突的发生,当发生合并冲突时,MM 提供基于 Web 的机制来解决它们。

仅供参考,它是一个商业工具。我听说过的唯一能做类似事情的开源工具是 Merge Fairy,但我不认为 Merge Fairy 的开发非常活跃。

请访问 http://www.timpanisoftware.com 查看。

You might find Timpani Software's MergeMagician project interesting. It is a branch management and automated merging solution that works with Subversion (and also Microsoft TFS). You create publish/subscribe relationships between branches, and then the server automates the merges.

Frequent merging as MM facilitates will reduce the occurrence of merge conflicts, and when they do happen, MM provides a web-based mechanism for resolving them.

FYI, it is a commercial tool. The only open source tool I've heard of that does anything close to this is Merge Fairy, but I don't think Merge Fairy is very actively developed.

Check it out at http://www.timpanisoftware.com.

难以启齿的温柔 2024-11-21 10:05:24

您可能只需要从主干合并回分支,而不是创建新分支......像这样:

Trunk
--- 创建 Sprint

--- 将 Sprint 合并到 Trunk 中
--- 将 Trunk 合并到 Sprint 中

Your probably just need to merge from the trunk back into your branches instead of creating new branches... something like this:

Trunk
--- Create Sprint

--- Merge Sprint into Trunk
--- Merge Trunk into Sprint

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文