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.heide_at_trapezegroup.com
Stefan Sperling <stsp_at_elego.de>
2010-03-05 05:33 AM
To
Brad Heide <Brad.Heide_at_trapezegroup.com>
cc
users_at_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
Received on 2010-03-05 19:40:59 CET