Is it safe to ignore changes in svn:mergeinfo after an SVN merge?

Question

I am trying to merge a single commit with revision 1000 (affecting six Java files) from the trunk into a branch. Executing the following commands showed exactly the same effect:

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

This causes not only the expected six Java files to change, but dozens of other files and directories (but not everything in the repo). Why does that happen? When looking at what exactly changed in a file where I expected no changes at all, it always looks something like this:

> svn diff SomeOtherFile.java

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

Is it okay to revert all the changed svn:mergeinfo files and directories and only commit exactly those six Java files that I originally thought to merge? What are the consequences?

Answer 1

When you do a merge in Subversion, you should almost always be merging to the base of the project. This is true even if the target of the file you're merging is buried deep in the directory hierarchy.

Subversion uses properties (specifically the svn:mergeinfo property) to track merging. This property is added to the base where the merge takes place. If you merge only from the root of the project, only the project root will have this property. If you merge all over the place, you will have svn:mergeinfo properties scattered throughout your project. Anytime a merge happens, and there's a svn:mergeinfo property somewhere in that directory hierarchy, that property has to be updated.

Don't ignore these properties even if the directories they're on aren't changed. There may be a file in a sub-directory that depends upon that svn:mergeinfo .

Think of Subversion revisions as change sets . That is, a single revision is a single change that could affect multiple files. This is true of merging too. Let's say your project looks like this:

foo
  src
    test
       ...
    main
       resources
          ...
       java
           com
              vegicorp
                    ...
                    munge
                        frapify
                            purèe.java

On a branch, you have a revision that includes a change in purèe.java that you want to merge into trunk. It's easy to go into the foo/src/main/java/com/vegicorp/munge/frapify directory and handle the merge from there. That creates a svn:merginfo on the frapify directory that will be with you forever and ever and ever. Every time you do a merge in any parent directory, you'll get a change with that svn:mergeinfo .

Instead, do the merge on the root of the project, the foo directory. Your merge will still only affect the purèe.java file, but the svn:mergeinfo changed will be the one on the foo directory where all the other merges will take place.

So, you can't ignore the svn:mergeinfo . The best that will happen is that Subversion will think that a particular revision hasn't been merged, and will do another merge again with that revision. The worst is that you mess up the merge results, and you'll end up doubling up a merge.

There is a way to clean up this mess. Go through all the svn:mergeinfo properties in the hierarchy and make sure that the root of the project has all of these revisions in its merge info. If not, merge those changes in at the root. Once you have the root's svn:mergeinfo containing every single merge, you can delete the other svn:mergeinfo scattered throughout the project.

However, if you don't get your developers to do their merges in the root of the project, you will simply end up with the same mess a few months from now. So, it's important to train your developers.

Developers are stubborn creatures who insist on doing things their own way. We used Maven on on site which has a default directory layout, and one team insisted that they prefer their own directory layout. It caused us all sorts of problems with the project, but it took a massive deployment failure due to this team's shenanigans, where they were told either do it the way everyone else does it (and the way Maven wants it) or find a new job.

Even after that, the project lead kept telling me how wrong the directory layout is and that if everyone else on the project simply followed his logical and improved directory layout, everything would be fine.