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).