On Thu, Jul 14, 2016 at 09:38:05PM -0400, Alfred von Campe wrote: > A user at work came to me with a strange merge issue and I have been able to > reproduce it. This happens with both a 1.8.16 and 1.9.4 Linux CLI client. I > usually can resolve these merge issues by deleting superfluous svn:mergeinfo > properties in subdirectories and/or by editing the svn:mergeinfo property, > but nothing works in this case. Here is some information I captured; the > only thing that has been altered is the name of the branches to protect our > data. All commands were performed in a fresh checkout of the tip of branchB. > > TIA for any help or hints to help resolve this issue. > > Alfred
Hi Alfred, I'm afraid it's not obvious to me what issue you are referring to. Which behaviour are you expecting, and how does Subversion not meet your expectations? > > > $ svn mergeinfo ^/branches/branchA > youngest common ancestor > | last full merge > | | tip of branch > | | | repository path > > 15542 29501 > | | > --| |------------ branches/branchA > ... / / > \ / > --| |------------ branches/branchB > | | > 28907 WC > $ svn pg svn:mergeinfo | grep branchA > /branches/branchA:28000-29203 > $ svn pe svn:mergeinfo . > Set new value for property 'svn:mergeinfo' on '.' > $ svn pg svn:mergeinfo | grep branchA > /branches/branchA:15542-29203 > $ svn mergeinfo ^/branches/branchA --show-revs=eligible > r15544 > r15583 > [360 revs deleted] > r20783 > r20790 > r20801 > r29207 > r29211 > r29279 > r29303 > r29306 > r29398 > r29425 > r29427 > r29479 > r29482 > r29496 > r29500
