linux - 多人项目上的 SVN 补丁/差异管理

Question

我通常从事仅涉及 2-3 人同时处理同一代码库的小型项目。

我平时的作息是这样的:

1. 搜索错误报告，按优先级选择错误，并编写修复程序
2. 创建代码库更改的差异/补丁(让我们称之为补丁“alpha”)(即:svn diff > ~/diff_alpha.patch)
3. 将补丁通过电子邮件发送给同事，他们可以在其中直观地检查代码库的差异并指出错误或建议
4. 他们告诉我需要进行哪些更改，我将其放入，然后将修改后的补丁通过电子邮件发送给我的团队
5. 一旦每个人都认为补丁是好的，我就会将它应用到代码库，必要时合并其他人的更改，重新构建、重新测试并提交。

这里的问题是，我通常需要等待几天才能收到修改后的最终补丁的所有批准，而在此期间我(显然)想处理其他补丁。

如果我开始处理另一个错误并且它影响了我在前一个补丁中处理的同一个文件，这意味着当我想提交前一个补丁(alpha)时，我必须:

1. 通过 svn diff > ~/diff_bravo.patch
将我当前的工作备份到一个新补丁(即:补丁“bravo”)
2. 还原我当前的工作副本 (svn revert -R .)
3. 应用旧补丁(patch -p0 < ~/diff_alpha.patch)
4. 提交旧补丁(svn commit)
5. 应用我之前正在处理的补丁 (patch -p0 < ~/diff_bravo.patch)
6. 继续处理与 diff_bravo.patch 相关的代码

这很烦人，因为我通常必须手动合并 diff_alpha 和 diff_bravo 之间的冲突。

我尝试的另一种方法是继续我在 diff_alpha 上的工作，而不创建 diff_bravo。然后，当我批准我通过电子邮件发送的原始 diff_alpha 中的所有代码时，我将执行以下操作:

1. 通过 svn diff > ~/diff_temp.patch
将我当前的工作备份到新补丁(即:补丁“temp”)
2. 还原我当前的工作副本 (svn revert -R .)
3. 应用旧补丁(patch -p0 < ~/diff_alpha.patch)
4. 提交旧补丁(svn commit)
5. 应用我之前处理的补丁 (patch -p0 < ~/diff_temp.patch)
6. 现在我可以继续我正在做的事情而不必手动合并，但我会在我的“补丁”命令中收到大量失败的信息，因为 diff_temp 中的一半代码已经提交到 diff_alpha 中。我认为这是 Not Acceptable 。

对于处理公共(public)文件上的多个任务/错误有什么建议可以最大限度地减少 SVN 冲突？

Answer 1

这就是分支的用途。您为每个错误创建一个分支并在该分支中工作，直到您准备好与您的团队成员协商。该分支可以由团队成员 checkout 并检查(当您进行新更改时更新)。当每个人都同意时，将分支合并回主干。

团队成员可以检查您对分支所做的每个更改的日志(基本上是您问题中的补丁)或打开更改的文件并在上下文中查看应用的更改(他们甚至可以访问以前版本的文件以查看更改前的情况)。

您仍然需要提醒您的团队成员检查更改，但不必自己明确向他们发送更改——他们将从中央存储库中获取更改。

您可以有多个分支(每个错误一个)并且可以同时处理它们。合并到主干时，SVN应该自动合并(偶尔会指出冲突，可以手动解决)。

冲突可能是因为分支是从旧版本的主干创建的，而当前主干状态(包含来自其他分支的一些更改)与当前分支中的更改冲突。你手动解决它们是有意义的。重新测试以确保一切正常。

更新:根据 Lazy Badger 的评论，您的团队成员可以放置提交监视器，以便在您对(特定)分支进行更改时提醒他们。