A single editor drive merge which adds a subtree with preexisting mergeinfo,
sets mergeinfo on the added subtree describing the merge, but reports this as
Mer' G'ed Rather than ' U'pdated.
For example:
>svn diff ^^/A -r8:10 --summarize
D
file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A/C
A
file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A/C_MOVED
M
file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A
>svn merge ^^/A A_COPY_2 -r8:10
--- Merging r9 through r10 into 'A_COPY_2':
A A_COPY_2\C_MOVED
U A_COPY_2
D A_COPY_2\C
--- Recording mergeinfo for merge of r9 through r10 into 'A_COPY_2':
G A_COPY_2
--- Recording mergeinfo for merge of r9 through r10 into 'A_COPY_2\C_MOVED':
G A_COPY_2\C_MOVED
^^^^^^^^^^^^^^^^^^^^
C_MOVED should be reported as ' U'pdated.
This occurs because the mergetracking logic (see
libsvn_client/merge.c:process_children_with_new_mergeinfo) quietly applies the
added subtree's inherited mergeinfo to it's incoming explicit mergeinfo. This
makes sense for subtrees which existed prior to the merge with no mergeinfo,
since the mergeinfo those paths inherit could easily describe the subtree's
merge history (...should we add some type of notification for this or would it
just be a case of implementation details the user doesn't need to know about?).
For subtrees *added* by the merge though we would ideally skip this, since that
inherited mergeinfo likely describes non-existent path-revs at best, or other
lines of history at worst. However if we were to do this we'd run into issue
#4269 'subtree mergeinfo can degrade automatic merge performance'.
So in the short term we have a choice: Crippling merge performance *or* odd
merge notifications and some bogus mergeinfo (which is normal practice should be
quite harmless). We've done the latter since 1.5. Long term, if issue #4269 is
fixed we can fix this issue too.
Note that this issue applies only to added *directory* subtrees, added files are
treated inconsistently (which is the reason issue #4269 isn't a far more
widespread problem).
Bug
Trivial
