Noticed a minor mergeinfo recording bug in discussion with Julian (see
http://svn.haxx.se/dev/archive-2012-04/0399.shtml)
### Starting with our standard Greek tree that has two branches made
### from ^/A in r2 and r3, and some simple text changes made under
### ^/A in r4-7
### Switch a subdirectory and a file in what will be our merge target
>svn sw ^^/A_COPY_2/C A_COPY\C
At revision 7.
>svn sw ^^/A_COPY_2/B/lambda A_COPY\B\lambda
At revision 7.
>svn st
S A_COPY\B\lambda
S A_COPY\C
### Delete the corresponding subdirectory and file in our "trunk":
>svn del A\C
D A\C
>svn del A\B\lambda
D A\B\lambda
>svn ci -m ""
Deleting A\B\lambda
Deleting A\C
Committed revision 8.
>svn up
Updating '.':
At revision 8.
### Merge the above deletion from "trunk" to the WC where the
### to-be-deleted targets are switched:
>svn merge ^^/A A_COPY -c8
--- Merging r8 into 'A_COPY\B':
D A_COPY\B\lambda
--- Merging r8 into 'A_COPY':
D A_COPY\C
--- Recording mergeinfo for merge of r8 into 'A_COPY':
U A_COPY
--- Recording mergeinfo for merge of r8 into 'A_COPY\B':
U A_COPY\B
>svn st
M A_COPY
D A_COPY\C
M A_COPY\B
D A_COPY\B\lambda
### There is no need for non-inheritable mergeinfo here!
### If A_COPY\C or A_COPY\B\lambda were modified rather than
### deleted, then yes, non-inheritable mergeinfo makes sense,
### but with those subtrees *gone*, normal inheritable mergeinfo
### accurately describes the merge.
>svn pl -vR
Properties on 'A_COPY':
svn:mergeinfo
/A:8*
Properties on 'A_COPY\B':
svn:mergeinfo
/A/B:8*
>
Bug
Minor