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
Received on 2016-07-15 09:02:43 CEST