1

我首先会说这完全有可能是不可能的——如果不是，那很好（好吧，这很糟糕，但我会活下去）。我知道可能会有一些“好吧，那无论如何会如何工作？” 围墙在做我想做的事，但是嘿嘿。

我想做的是在不更改任何所有权数据的情况下重新格式化 Subversion 存储库中的大量文件，或者将其变为：

username   | commit number
------------------------------------------------
john_smith | 1 | <?php
john_smith | 1 | echo 'Hello world';
joe_bloggs | 2 | if (isset($user)) {
john_doe   | 3 |   echo ', and hello ' . $user;
joe_bloggs | 2 | }

进入这个（新行是无主的）：

username   | commit number
------------------------------------------------
john_smith | 1 | <?php
           |   |
john_smith | 1 | echo 'Hello world';
joe_bloggs | 2 | if (isset($user))
           |   | {
john_doe   | 3 |   echo ', and hello ' . $user;
joe_bloggs | 2 | }

或者这个（新行归我所有，但更改的行不是）：

username   | commit number
------------------------------------------------
john_smith | 1 | <?php
mr_man     | 4 |
john_smith | 1 | echo 'Hello world';
joe_bloggs | 2 | if (isset($user))
mr_man     | 4 | {
john_doe   | 3 |   echo ', and hello ' . $user;
joe_bloggs | 2 | }

或任何其他排列。

我想这样做，因为存储库中有很多格式错误的代码，我想在不拥有（几乎）整个事情的所有权的情况下清理它，因为能够很方便地击中 Blame在文件的一侧，查看每一行的最后更改，以及这些更改的原因。使用提交消息和所有权重新格式化将删除存储库的大部分内容，并迫使我们在日志中查找真实的人，然后对其进行比较以确保。

如果有人能想出另一种方法来重新格式化代码而不破坏 Blame，我也愿意就此提出建议。

4

1 回答 1

2

你能做到吗？不会。文件中的任何更改都会创建另一个修订版。因此，您将在svn blame每一行中获得一个新的修订号。毕竟，即使是无害的更改也可能导致问题。如果您的重新格式化操作更改了破坏应用程序的数据怎么办。仔细格式化该数据的开发人员不希望发现自己因此受到指责。这就是为什么即使格式更改也会更改修订。

如果需要，您可以做一些事情：修订的所有者是svn:author. 如果更改该修订属性，则可以更改执行提交的用户的名称。

有点限制：

  • 每个提交只有一个作者，因此您必须安排提交以完成特定作者的所有文件。
  • 默认情况下，Subversion 不允许您更改修订属性。您必须创建一个预修订更改挂钩以允许您更改该属性。
  • 所有行都将在 中显示为该作者，blame并且显示的修订版将是您进行更改时的修订版。

我的建议：不要这样做。如果没有经过彻底测试，您可能会破坏某些东西。我建议使用Jenkins 之类的东西。我意识到 PHP 文件不需要像 Java 或 C 代码那样编译，但您可以对文件运行语法检查器并在 Jenkins 中显示结果。

您也许可以将phpcheckstyle应用程序与 Jenkins Checkstyle 插件一起使用。然后使用 cigame 插件挑战开发人员修复代码本身的格式。

每个已修复的 checkstyle 违规都会给开发人员在 cigame 插件中的积分。这将鼓励开发人员自己修复格式问题。如果您不是开发人员，则不应接触代码。否则，Finger o' Blame 可能会从创建错误代码的开发人员那里指向您，因为您更改了它——即使它只是格式化。

于 2012-10-23T16:30:44.487 回答