在SVN合并后忽略svn:mergeinfo中的更改是否安全？

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想要的方式)或找到一份新工作,这需要大规模的部署失败. .

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