Svn 合并Subversion中遗漏的更改

我的开发团队遵循Subversion中不稳定的主干、稳定的分支模式。每个月，从主干创建一个稳定的发布分支。有时，需要将这些发布分支中的更改合并到后续发布分支中，并最终合并到主干中

问题是，在过去的几个月里，所有这些分支机构的合并都是错误的。由于开发人员误解了需要合并的修订，许多修订被跳过

不正确的合并历史记录示例如下所示：

------------------------------------------------------------------------
r57 | Bob | 2008-11-27 04:02:46 -0600 (Thu, 27 Nov 2008) | 1 line

action:merge; origin:branches/1; target:branches/2; range:28-55
------------------------------------------------------------------------
r28 | Alice | 2008-11-25 10:14:00 -0600 (Tue, 25 Nov 2008) | 1 line

action:merge; origin:branches/1; target:branches/2; range:10-25

在这里，Bob应该从r25开始合并，Alice的合并在r25结束，而不是r28

因此，现在我有6个分支机构从10月初以来以这种方式被错误地合并。这会导致测试失败和主干中的许多倒退。现在，我想返回并合并所有遗漏的更改

是否有一种简单且正确的方法来做到这一点？我目前的计划是回到起点，开始在每个间隙合并。所以在这个例子中，我将把修订版25-28从分支1合并到分支2。但我预计会有很多冲突，我希望有更好的办法

---

对于这个问题，真的没有快速简单的解决方法。强迫开发人员在Subversion中维护多个并发分支容易出错且耗时。在这种情况下，许多开发人员的签入注释无论如何都是不准确的。因此，真的没有办法回到过去，回到过去。相反，我们将完全测试最新的分支并关闭其余的分支。

如果开发人员正在检查他们在分支中的更改，您不能在合并之前创建一个新分支，正确地合并更改，然后合并他们的新代码吗？也许我错过了什么

---

我不熟悉各种Subversion模式，但我的公司遵循这样一个过程：主干始终是稳定的，开发人员无法更改它（只能更改分支）。因此，我们从未遇到过合并问题，我们在SVN中有10000多个修订版本和100个分支。我之所以提出这个问题，是因为如果有多个开发人员出现合并问题，那么您的流程/模式中似乎存在一个重大缺陷。

如果开发人员在合并过程中检查分支中的更改，您不能在合并之前创建一个新分支，正确合并更改，然后合并新代码吗？也许我错过了什么

---

我不熟悉各种Subversion模式，但我的公司遵循这样一个过程：主干始终是稳定的，开发人员无法更改它（只能更改分支）。因此，我们从未遇到过合并问题，我们在SVN中有10000多个修订版本和100个分支。我之所以提出这个问题，是因为如果有多个开发人员存在合并问题，那么您的流程/模式中似乎存在一个重大缺陷。

好吧，要获得所有内容，您只需合并到URL，而无需进行特定的修订。例如：

cd /path/to/working/copy/of/stable/brunch
svn merge https://company.com/repo/project/branch/stable https://company.com/repo/project/trunk

---

这样你们就可以从你们忘记合并到马厩里的箱子里得到所有东西。查看、还原您不需要的内容，然后提交。

好吧，要获得所有内容，您只需合并到URL而无需进行特定修订。例如：

cd /path/to/working/copy/of/stable/brunch
svn merge https://company.com/repo/project/branch/stable https://company.com/repo/project/trunk

---

这样你们就可以从你们忘记合并到马厩里的箱子里得到所有东西。查看、还原您不需要的内容，然后提交。

这听起来真是一个可怕的策略，而且容易出错。我一直努力坚持“只在必要时才分支，尽可能晚”的概念。我确信我遗漏了一些东西，只是没有遇到按你的方式做的必要，但对我来说，这听起来像是在招惹麻烦。这听起来真是一个可怕的政策，而且容易出错。我一直努力坚持“只在必要时才分支，尽可能晚”的概念。我确信我遗漏了一些东西，只是没有遇到按你的方式做的需要，但对我来说，这听起来像是在招惹麻烦。我们刚刚讨论了两种不同的分支技术。我必须说，它们各有优点和问题。与其他源代码管理软件合作后，我认为Subversion可以做得更好，但我不确定如何做。我们刚刚讨论了两种不同的分支技术。我必须说，它们各有优点和问题。与其他源代码控制软件合作后，我认为Subversion可以做得更好，但我不确定如何做。