我通常从事小型项目，只涉及2-3个人同时在同一个代码库上工作。
对我来说，通常的例行程序如下：
这里的问题是我通常需要等待几天才能获得修改后的最终补丁的所有批准，在此期间我（显然）想要处理其他补丁。
如果我继续处理另一个bug，它会影响我在上一个补丁中处理的同一个文件，这意味着当我想提交之前的补丁（alpha）时，我必须：
这很烦人，因为我通常不得不在diff_alpha和diff_bravo之间手动合并冲突。
我尝试的另一种方法是继续我的diff_alpha工作而不创建diff_bravo。然后，当我批准通过电子邮件发送的原始diff_alpha中的所有代码时，我会执行以下操作：
有关处理公共文件上的多个任务/错误的任何建议，以便最大限度地减少SVN冲突吗？
答案 0 :(得分：3)
这就是分支机构的用途。您为每个错误创建一个分支并在该分支中工作，直到您准备好与您的团队成员协商。团队成员可以检查分支并进行检查（进行新更改时更新）。当每个人都同意时，将分支合并回主干。
团队成员可以检查您对分支所做的每项更改的日志（实际上是您的问题中的补丁），或者打开已更改的文件并查看上下文中应用的更改（他们甚至可以访问以前的版本）文件以查看更改之前的情况。）
您仍然需要提醒您的团队成员检查更改，但不必明确地向他们发送更改 - 他们将从中心存储库中获取更改。
您可以拥有多个分支（每个bug一个），并且可以同时处理它们。合并到主干时，SVN应自动进行合并（偶尔指出冲突，你可以手动解决。
冲突可能是因为分支是从旧版本的trunk创建的，而当前的trunk状态（包含其他分支的一些更改）与当前分支的更改冲突。你有意义地手动解决它们。重新测试以确保一切都很好。
更新：根据Lazy Badger的评论，您的团队成员可以提交提交监视器，以便在您对（特定）分支进行更改时提醒他们。
答案 1 :(得分：2)
当我们工作时，我们会在提交后进行大部分代码审查。这些补丁文件都没有来回传递。我们使用Jenkins并拥有可以为我们进行大量检查的插件（如Findbugs，PMD，CheckStyle等）。如果我们发现问题，我们可以在新的提交中修复它们。如果变化很糟糕，我们可以将其还原。
如果您喜欢当前的工作流程，可能需要查看Git，它允许您在开发人员之间轻松共享这样的补丁。这是Git如此受欢迎的原因之一。
我还有一个用于Subversion的 Commit Monitor 插件（真正的提交后挂钩），允许人们根据他们想要通知的更改来设置自己的首选项。配置存储在存储库中，因此用户可以访问它。