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

Question

我通常从事小型项目，只涉及2-3人同时从事同一代码基的工作。

我通常的例行公事如下：

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

这里的问题是，我通常需要等待几天才能获得修改后的最后补丁的批准，而在此期间，我(显然)希望在其他补丁上工作。

如果我在另一个bug上工作，并且它影响到我在上一个修补程序中处理的同一个文件，这意味着当我想提交上一个修补程序(alpha)时，我必须：

1. 通过svn > ~/diff_bravo.patch将我当前的工作备份到一个新的修补程序(即:修补程序"bravo")
2. 还原我当前的工作副本(svn还原-R )。
3. 应用旧补丁(补丁-p0 <~/diff_ Apply .修补程序)
4. 提交旧修补程序(svn提交)
5. 应用我以前使用的修补程序(修补程序~/diff_bravo.patch) < -p0 )
6. 继续处理与diff_bravo.patch相关的代码

这是很烦人的，因为我通常不得不手工合并diff_alpha和diff_bravo之间的冲突。

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

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

对于处理公共文件上的多个任务/错误，有什么建议吗?这样我就可以最小化SVN冲突了？

Answer 1

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

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

您仍然必须提醒您的团队成员检查这些更改，但不必显式地将更改发送给他们--他们将从中央存储库获得更改。

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

冲突可能产生于这样一个事实:分支是从较早版本的主干创建的，而当前主干状态(包含来自其他分支的一些更改)与当前分支中的更改相冲突。您可以手动解析它们，因为这是有意义的。再做一次测试以确保一切正常。

更新:基于Lazy的评论，您的团队成员可以在更改(特定)分支时设置提交监视器，以提醒他们。

Answer 2

当我们工作时，我们会在提交发生之后进行大部分代码评审。所有这些补丁文件都不会来回运行。我们使用Jenkins，并且有插件可以为我们进行大量的检查(比如Findbug、PMD、CheckStyle等等)。如果我们发现问题，我们可以在一个新的提交中修复它们。如果改变不好，我们可以恢复它。

如果您喜欢当前的工作流程，您可能需要查看Git，它允许您在开发人员之间很容易地共享这样的修补程序。这也是Git如此受欢迎的原因之一。

我还为Subversion提供了一个https://github.com/qazwart/SVN-Watcher-Hook插件(实际上是一个post提交钩子)，它允许人们设置自己的首选项，以了解他们想要得到的更改。配置存储在存储库中，因此用户可以访问它。