As Julian noted in
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?r1=1205867&r2=1205866&pathrev=1205867
there is a bug in the merge code when tracking the roots of subtrees added by a
merge in libsvn_client/merge.c:
[[[
--- subversion/trunk/subversion/libsvn_client/merge.c 2011/11/24 15:09:12 1205866
+++ subversion/trunk/subversion/libsvn_client/merge.c 2011/11/24 15:09:16 1205867
@@ -2795,6 +2795,7 @@
notify_abspath = moved_to_abspath;
}
+ /* Update the lists of merged, skipped, tree-conflicted and added paths. */
if (notify_b->merge_b->sources_ancestral
|| notify_b->merge_b->reintegrate_merge)
{
@@ -2856,6 +2857,9 @@
else
{
added_path_parent = svn_dirent_dirname(added_path, pool);
+ /* ### Bug. Testing whether its immediate parent is in the
+ * hash isn't enough: this is letting every other level of
+ * the added subtree hierarchy into the hash. */
if (!apr_hash_get(notify_b->added_abspaths, added_path_parent,
APR_HASH_KEY_STRING))
is_root_of_added_subtree = TRUE;
]]]
This went unnoticed for so long because the only consumer of ADDED_ABSPATHS,
merge.c:record_mergeinfo_for_added_subtrees() only did anything with non-roots
if they had non-inheritable mergeinfo. In that case spurious mergeinfo could be
created, but it takes a fairly tortured use case to do so.
Bug
Minor
