更新分支后从主干合并 svn 使我成为大量文件修改的作者

Question

cd my/branch
svn up
svn merge my/trunk
svn commit -m 'merged from trunk'

然后我用

svn blame somefile

我看到一些不是我做的更改，但说它的作者是我。

我的问题是，这是在 svn 中开发分支的正常工作流程吗？如果我是提交者，即使这些更改只是来自 svn update 或 svn merge，作者应该是我吗？

Answer 1

是的，为什么你是合并的作者？这不像您提交了代码中的更改。哦，等一下……没关系。我的错。

作者始终是 Subversion 中的提交者。当您进行合并时，您是负责验证更改是否有效的人。即使没有合并冲突，也不意味着合并确实有效。可能存在标准合并无法检测到但同样致命的逻辑合并冲突。这就是为什么进行合并的人仍然必须测试和验证他们的工作。

当人们使用 pristine trunk 方法工作时，我通常会看到这个问题。您假设将您的工作合并到包含发布代码的主干。开发人员在分支上开发他们的代码，发布工程师负责将此代码移动到主干。

我不喜欢这种方法：

• 正如您所说，您现在是代码更改的责任。
• 当您执行svn log 时，默认情况下日志会沿着主干传输，这不会告诉您任何有关历史的信息。你所看到的只是发布工程师做了一个又一个的更改。
• 通常，您的想法是为每个版本从主干分支，但您最终会在上一个版本完成之前分支到下一个版本，这意味着您通常最终会丢失下一个版本中已修复的错误修复以前的版本。
• 要记住合并回主干需要做很多工作。
• 而且，甚至没有必要。您标记发布，您可以查看发布的内容并通过标记比较发布。

我更喜欢将 trunk 作为主要代码分支。当您将要处理多个版本时，您分支 离开主干以进行发布，并将您的版本标记为分支。如果您需要错误修复或补丁，您可以使用一个分支。

此过程不会消除功能分支。您不必必须仅在主干上进行开发。它消除了对原始主干的需要，该主干难以维护并且几乎没有为开发过程增加任何价值。

Answer 2

您是合并修订的作者，因此对于 SVN（本修订的内部责备）您是更改字符串的作者 - 责备不执行任何回顾性分析，也不区分合并提交和普通提交

这就是svn中分支开发的正常工作流程吗

是的。这是（任何）VCS 的绝对正常和标准用法