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 11:33:37 CET