Thanks Stefan. You are correct that the example I chose (r38300) had not originally been applied at the root of the branch however I don't believe that was the cause of the problem. I tried re-merging another revision that had been originally applied to the root of the same branch and I got the same list files and folders that should not have been touched minus the root folder. So in the example I sent you it was correct that the root folder of the branch should have been updated with the revision number but not the other diffs that showed up.
I took a closer look at the mergeinfo revision numbers stamped on the affected files and many of them appeared to point to revisions that had nothing to do with that file. Here is an example for file CliShell.cpp (the root of the working folder is C:\Dev\ModuleTests\Core3-3.15.x\Modules\Core) C:\Dev\ModuleTests\Core3-3.15.x\Modules\Core\Exe\CliShell\CliShell.cpp /modules/Core3/branches/3.12.x/Exe/CliShell/CliShell.cpp:31673 /modules/Core3/branches/3.14.x/Exe/CliShell/CliShell.cpp:33671,33721-33777,33781,33788,33795-33815,33832,33834,33843,33860,33904-33915,33921,33928,33945,34136,34292,34317,34394,34419,34968,35879,35947,36082-36093,36247,36253 /modules/Core3/branches/3.15.x/Exe/CliShell/CliShell.cpp:33601,33864 /modules/Core3/trunk/Exe/CliShell/CliShell.cpp:37590,37594,37693,37705,37719,37804,37822 For example, when I look at the history of revision 31673 in branch /modules/Core3/branches/3.12.x this is the only change in the log: /modules/Core3/branches/3.12.x/Res/Std/En_US/str/Global.string So revision 31673 had nothing to do with CliShell.cpp. How this revision got stamped on the mergeinfo of CliShell.cpp in the 3.15.x branch I have no idea. Figuring that the merginfo was all messed up on the affected files and folders, I removed the mergeinfo property from just the affected files and folders and committed the change. I then re-ran my test of re-merging something that was already merged and this time no differences showed up in the working folder (good!) So my problem appears to be fixed for now. How the bad mergeinfo got on these particular files I still don't know but I will keep an eye out to see if it happens again. Thank you for your help and prompt response in this matter. Brad. brad.he...@trapezegroup.com Stefan Sperling <s...@elego.de> 2010-03-05 05:33 AM To Brad Heide <brad.he...@trapezegroup.com> cc users@subversion.apache.org Subject Re: SVN Bug? mergeinfo being stamped on wrong files On Thu, Mar 04, 2010 at 04:27:16PM -0500, Brad Heide wrote: > C:\Dev\ModuleTests\Core3-3.15.x\Modules\Core>svn merge -c 38300 > ..\..\..\_Core3-trunk\Modules\Core > > (It just so happens that revision 38300 has already been merged to this > branch so we expect the result of this merge operation to be no changes in > the working copy, but lets check for diffs anyhow...) This merge was however never recorded in the mergeinfo at branch's root. Else you would not see this bit show up in the diff: > Property changes on: . > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /modules/Core3/trunk:r38300 You should check with your developers how they are doing merges. Mergeinfo is always recorded at the merge target. If people merge into individual files directly, those files will get mergeinfo set on them. This makes Subversion's mergetracking very flexible, but the mergeinfo will spread across branches and can end up being a nuisance if people using the repository don't have a common idea of merging guidelines, or if some users don't follow guidelines and end up polluting the repository with mergeinfo excessively. I usually recommend to define a set of paths in the repository where mergeinfo is allowed to be set -- let's call these paths "mergeinfo nodes". The set of mergeinfo nodes normally contains just the root folders of branches. But it can be larger in case you have special requirements such as a separate team merging into some subdirectory of a branch, because that subdirectory is the scope of their activities in the repository. Merging is then done only into targets within the mergeinfo node set. No other merge targets should be used. (Except if direct merges from one file to another need to be done as part of conflict resolution, for instance, if files were renamed on one branch but not the other. In this case, you can remove the mergeinfo created on the files, since conflict resolution is part of the larger merge you are doing.) As soon as mergeinfo enters the repository which is not on one of the mergeinfo nodes, the alarm bells should ring and mergeinfo needs to be cleaned up. If the above makes sense to you, what would be your set of "mergeinfo nodes", and are your users really only merging into those paths? Can you try to figure out when the mergeinfo on the affected files first entered the repository, and what kind of merge was done at that time? Stefan