在 SVN 合并后忽略 svn:mergeinfo 中的更改是否安全？
Is it safe to ignore changes in svn:mergeinfo after an SVN merge?
我正在尝试将主干中版本为 1000（影响六个 Java 文件）的单个提交合并到一个分支中。执行以下命令显示完全相同的效果：
svn merge -c1000 https://<my-project>/trunk
svn merge -r999:1000 https://<my-project>/trunk
这不仅会导致预期的六个 Java 文件发生变化，还会导致数十个其他文件和目录（但不是存储库中的所有内容）。为什么会这样？当查看文件中的确切更改时，我预计根本没有更改，它总是看起来像这样：
> svn diff SomeOtherFile.java
Property changes on: SomeOtherFile.java
___________________________________________________________________
Modified: svn:mergeinfo
Merged SomeOtherFile.java:r1000
是否可以还原所有已更改的 svn:mergeinfo 文件和目录并且只提交我最初想合并的那六个 Java 文件？有什么后果？
当你在 Subversion 中进行合并时，你应该几乎总是合并到项目的基础上。即使您要合并的文件的目标深埋在目录层次结构中也是如此。
Subversion 使用属性（特别是 svn:mergeinfo 属性）来跟踪合并。此 属性 被添加到发生合并的基础中。如果只从项目根合并，只有项目根会有这个属性。如果你在所有地方合并，你将有 svn:mergeinfo 属性分散在你的项目中。任何时候发生合并，并且在该目录层次结构中的某处有 svn:mergeinfo 属性，必须更新 属性。
不要忽略这些属性，即使它们所在的目录没有改变。子目录中可能有一个文件依赖于 svn:mergeinfo.
将 Subversion 修订视为 变更集 。也就是说，单个修订是可能影响多个文件的单个更改。合并也是如此。假设您的项目如下所示：
foo
src
test
...
main
resources
...
java
com
vegicorp
...
munge
frapify
purèe.java
在分支上，您有一个修订，其中包含您要合并到主干中的 purèe.java 更改。很容易进入 foo/src/main/java/com/vegicorp/munge/frapify 目录并从那里处理合并。这会在 frapify 目录中创建一个 svn:merginfo，它将永远与您同在。每次在任何父目录中进行合并时，您都会得到 svn:mergeinfo.
的更改
相反，在项目的根目录 foo 目录中进行合并。您的合并仍然只会影响 purèe.java 文件，但 svn:mergeinfo 更改将是 foo 目录中的文件，所有其他合并都将在该目录中进行。
因此，您不能忽略 svn:mergeinfo。最好的结果是 Subversion 会认为一个特定的修订版还没有被合并，并且会再次对该修订版进行另一个合并。最糟糕的是你弄乱了合并结果，你最终会加倍合并。
有办法收拾这个烂摊子。遍历层次结构中的所有 svn:mergeinfo 属性，并确保项目的根在其合并信息中包含所有这些修订。如果不是，请将这些更改合并到根目录中。一旦根的 svn:mergeinfo 包含每个合并，您就可以删除分散在整个项目中的其他 svn:mergeinfo。
但是，如果您不让您的开发人员在项目的根目录中进行合并，那么几个月后您只会遇到同样的混乱。因此，培训您的开发人员非常重要。
开发人员是顽固的生物，他们坚持按照自己的方式做事。我们在现场使用具有默认目录布局的 Maven，并且一个团队坚持他们更喜欢自己的目录布局。它给我们的项目带来了各种各样的问题，但由于这个团队的恶作剧，导致大规模部署失败，他们被告知要么按照其他人的方式（以及 Maven 想要的方式）去做，要么找一份新工作.
甚至在那之后，项目负责人一直告诉我目录布局有多么错误，如果项目中的其他人都简单地遵循他的逻辑和改进的目录布局，一切都会好起来的。
我正在尝试将主干中版本为 1000（影响六个 Java 文件）的单个提交合并到一个分支中。执行以下命令显示完全相同的效果：
svn merge -c1000 https://<my-project>/trunk
svn merge -r999:1000 https://<my-project>/trunk
这不仅会导致预期的六个 Java 文件发生变化，还会导致数十个其他文件和目录（但不是存储库中的所有内容）。为什么会这样？当查看文件中的确切更改时，我预计根本没有更改，它总是看起来像这样：
> svn diff SomeOtherFile.java
Property changes on: SomeOtherFile.java
___________________________________________________________________
Modified: svn:mergeinfo
Merged SomeOtherFile.java:r1000
是否可以还原所有已更改的 svn:mergeinfo 文件和目录并且只提交我最初想合并的那六个 Java 文件？有什么后果？
当你在 Subversion 中进行合并时，你应该几乎总是合并到项目的基础上。即使您要合并的文件的目标深埋在目录层次结构中也是如此。
Subversion 使用属性（特别是 svn:mergeinfo 属性）来跟踪合并。此 属性 被添加到发生合并的基础中。如果只从项目根合并，只有项目根会有这个属性。如果你在所有地方合并，你将有 svn:mergeinfo 属性分散在你的项目中。任何时候发生合并，并且在该目录层次结构中的某处有 svn:mergeinfo 属性，必须更新 属性。
不要忽略这些属性，即使它们所在的目录没有改变。子目录中可能有一个文件依赖于 svn:mergeinfo.
将 Subversion 修订视为 变更集 。也就是说，单个修订是可能影响多个文件的单个更改。合并也是如此。假设您的项目如下所示：
foo
src
test
...
main
resources
...
java
com
vegicorp
...
munge
frapify
purèe.java
在分支上，您有一个修订，其中包含您要合并到主干中的 purèe.java 更改。很容易进入 foo/src/main/java/com/vegicorp/munge/frapify 目录并从那里处理合并。这会在 frapify 目录中创建一个 svn:merginfo，它将永远与您同在。每次在任何父目录中进行合并时，您都会得到 svn:mergeinfo.
相反，在项目的根目录 foo 目录中进行合并。您的合并仍然只会影响 purèe.java 文件，但 svn:mergeinfo 更改将是 foo 目录中的文件，所有其他合并都将在该目录中进行。
因此，您不能忽略 svn:mergeinfo。最好的结果是 Subversion 会认为一个特定的修订版还没有被合并，并且会再次对该修订版进行另一个合并。最糟糕的是你弄乱了合并结果，你最终会加倍合并。
有办法收拾这个烂摊子。遍历层次结构中的所有 svn:mergeinfo 属性，并确保项目的根在其合并信息中包含所有这些修订。如果不是，请将这些更改合并到根目录中。一旦根的 svn:mergeinfo 包含每个合并，您就可以删除分散在整个项目中的其他 svn:mergeinfo。
但是，如果您不让您的开发人员在项目的根目录中进行合并，那么几个月后您只会遇到同样的混乱。因此，培训您的开发人员非常重要。
开发人员是顽固的生物，他们坚持按照自己的方式做事。我们在现场使用具有默认目录布局的 Maven，并且一个团队坚持他们更喜欢自己的目录布局。它给我们的项目带来了各种各样的问题，但由于这个团队的恶作剧，导致大规模部署失败，他们被告知要么按照其他人的方式（以及 Maven 想要的方式）去做，要么找一份新工作.
甚至在那之后，项目负责人一直告诉我目录布局有多么错误，如果项目中的其他人都简单地遵循他的逻辑和改进的目录布局，一切都会好起来的。