You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alfred von Campe <al...@von-campe.com> on 2016/07/15 01:38:05 UTC

Strange merge problem

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


$ 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

Re: Strange merge problem

Posted by Alfred von Campe <al...@von-campe.com>.
On Jul 18, 2016, at 9:49, Andreas Stieger <an...@gmx.de> wrote:

> I wrote nothing of GUI.

Doh!  I just saw the “UI” in capital letters and complete missed the “cli” in lower case that preceded it - sorry about that!  Anyway, I’m no closer in resolving this merge issue, but will attempt to merge the revisions that I think have to be merged one by one and see what happens after that.

Alfred

Aw: Re: Strange merge problem

Posted by Andreas Stieger <An...@gmx.de>.
Hello,

> > Ideally use svn cli UI only.
> 
> Really?  I’ve had better luck using the CLI for merges.  So what GUI do you recommend using on Linux?

I wrote nothing of GUI.

Andreas

Re: Strange merge problem

Posted by Alfred von Campe <al...@von-campe.com>.
On Jul 18, 2016, at 3:00, Andreas Stieger <an...@gmx.de> wrote:

> Commonly caused by explicit subtree mergeinfo. Check for svn:mergeinfo properties set on subtrees for both the merge source and the merge target.

Unfortunately that’s not the case here.  While there was one svn:mergeinfo property in a subtree, removing it made no difference.

> Ideally use svn cli UI only.

Really?  I’ve had better luck using the CLI for merges.  So what GUI do you recommend using on Linux?

Alfred

Re: Strange merge problem

Posted by Andreas Stieger <An...@gmx.de>.
> $ 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 
> [100’s of revisions starting at 15544 including a
>  dozen or so expected ones after revision 29203]

Commonly caused by explicit subtree mergeinfo. Check for svn:mergeinfo properties set on subtrees for both the merge source and the merge target. 

> Somehow the merge info data got corrupted for these
> branches and I attempted to fix it by manually editing
> the svn:mergeinfo property.

Ideally use svn cli UI only.

Andreas

Re: Strange merge problem

Posted by Alfred von Campe <al...@von-campe.com>.
So is it me or is there something broken here?  A quick recap:

$ 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 
[100’s of revisions starting at 15544 including a
 dozen or so expected ones after revision 29203]

Somehow the merge info data got corrupted for these
branches and I attempted to fix it by manually editing
the svn:mergeinfo property.

Alfred


> On Jul 15, 2016, at 6:10, Alfred von Campe <al...@von-campe.com> wrote:
> 
> On Jul 15, 2016, at 3:02, Stefan Sperling <st...@elego.de> wrote:
> 
>> 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?
> 
> I expect Subversion to merge only revisions 29203:HEAD of branchA into
> branchB.  Why is it trying to merge everything from the youngest
> common ancestor when the svn:mergeinfo property (after I manually
> edited it) indicates that revisions 15542-29203 have already been
> merged?
> 
> Alfred

Re: Strange merge problem

Posted by Alfred von Campe <al...@von-campe.com>.
On Jul 15, 2016, at 3:02, Stefan Sperling <st...@elego.de> wrote:

> 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?

I expect Subversion to merge only revisions 29203:HEAD of branchA into
branchB.  Why is it trying to merge everything from the youngest
common ancestor when the svn:mergeinfo property (after I manually
edited it) indicates that revisions 15542-29203 have already been
merged?

Alfred

Re: Strange merge problem

Posted by Stefan Sperling <st...@elego.de>.
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