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