svn - 忽略 svn :mergeinfo after an SVN merge? 中的更改是否安全

Question

我正在尝试将修订版为 1000(影响六个 Java 文件)的单个提交从主干合并到一个分支中。执行以下命令显示完全相同的效果:

svn merge -c1000 https://<my-project>/trunk
svn merge -r999:1000 https://<my-project>/trunk

这不仅会导致预期的六个 Java 文件发生更改，还会导致数十个其他文件和目录(但不是 repo 中的所有内容)发生更改。为什么会这样？在查看我预计完全没有更改的文件中究竟发生了什么变化时，它总是看起来像这样:

> svn diff SomeOtherFile.java

Property changes on: SomeOtherFile.java
___________________________________________________________________
Modified: svn:mergeinfo
   Merged SomeOtherFile.java:r1000

是否可以恢复所有更改的 svn:mergeinfo 文件和目录，并且只提交我最初想合并的六个 Java 文件？后果是什么？

Answer 1

当您在 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 目录并从那里处理合并。这会在 svn:merginfo 目录中创建一个 frapify ，它将永远与您同在。每次在任何父目录中进行合并时，都会对 svn:mergeinfo 进行更改。

相反，在项目的根目录 foo 目录上进行合并。您的合并仍将仅影响 purèe.java 文件，但更改的 svn:mergeinfo 将是 foo 目录中的那个，所有其他合并都将在该目录中进行。

所以，你不能忽略 svn:mergeinfo 。最好的情况是 Subversion 会认为一个特定的修订版本没有被合并，并且会再次与该修订版本合并。最糟糕的是，您弄乱了合并结果，最终将合并加倍。

有一种方法可以清理这个烂摊子。检查层次结构中的所有 svn:mergeinfo 属性，并确保项目的根目录在其合并信息中包含所有这些修订。如果没有，请在根处合并这些更改。一旦您拥有包含每个合并的根的 svn:mergeinfo，您就可以删除分散在整个项目中的其他 svn:mergeinfo。

但是，如果您不让您的开发人员在项目的根目录中进行合并，那么几个月后您只会遇到同样的困惑。因此，培训您的开发人员很重要。

开发人员是顽固的生物，他们坚持以自己的方式做事。我们在现场使用了 Maven，它有一个默认的目录布局，一个团队坚持他们更喜欢他们自己的目录布局。它给我们的项目带来了各种各样的问题，但由于这个团队的恶作剧，导致大规模部署失败，他们被告知要么按照其他人的方式(以及 Maven 想要的方式)做，要么找一份新工作.

即使在那之后，项目负责人一直告诉我目录布局有多么错误，如果项目中的其他人都遵循他的逻辑和改进的目录布局，一切都会好起来的。