Branch synch merge from trunk fails with reintegrate error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Branch synch merge from trunk fails with reintegrate error

Todd Armstrong-2

I am attempting to merge updates to trunk (^/apps/trunk/pim) that were merged up from the branch of last year’s version where they originally made  (^/apps/branches/2016/pim) down into the branch of the current year’s version (^/apps/branches/2017/pim) and I am getting  an error indicating I can’t do a re-integrate merge, which I don’t think I’m trying to do.  The current year’s branch was created from trunk as of revision 8026, which is the revision before the beginning of the revision range given in the reintegrate error message. 

 

It seems to me this should be doing a synch merge from trunk down to branch and since the current year’s version and the trunk both have changes to a couple of the same files after the branch for the current year’s version was created, I expected to instead be getting a conflict to resolve.

 

Am I misunderstanding something about how a merge update from trunk to branch is supposed to work?  If not, how do I make it work as I expect?

 

# pwd

/u/delta/pim/42 

^^ base directory of working copy for current version’s branch)

 

# svn merge ^/apps/trunk/pim --dry-run

^^ related URL path in trunk

svn: E195016: Reintegrate can only be used if revisions 8027 through 9155 were previously merged from http://source.newscyclesolutions.com/svn/commerce/circulation/apps/branches/2017/delta/pim to the reintegrate source, but this is not the case:

  apps/trunk/pim

    Missing ranges: /apps/branches/2017/delta/pim:8027

 

I’m using the command line client (1.8.16) on CentOS 6.8.

# svn --version

svn, version 1.8.16 (r1740329)

   compiled Jul  6 2016, 11:38:59 on x86_64-redhat-linux-gnu

 

In case it’s useful, here’s mergeinfo regarding the current year’s branch and trunk and some related log details….

 

From branch working copy:

# pwd

/u/delta/pim/42

 

# svn mergeinfo ^/apps/trunk/pim

    youngest common ancestor

    |         last full merge

    |         |        tip of branch

    |         |        |         repository path

 

    8026               9155

    |                  |

  -------| |------------         apps/trunk/pim

     \          /

      \        /

       --| |------------         apps/branches/2017/delta/pim

              |        |

              8066     8328

 

# svn log version -v | more

------------------------------------------------------------------------

r8066 | gah | 2017-03-22 12:31:20 -0500 (Wed, 22 Mar 2017) | 1 line

Changed paths:

   M /apps/branches/2017/delta/pim

   M /apps/branches/2017/delta/pim/version

 

Updating version

------------------------------------------------------------------------

r8027 | prf | 2017-03-21 20:58:57 -0500 (Tue, 21 Mar 2017) | 1 line

Changed paths:

   A /apps/branches/2017/delta/pim (from /apps/trunk/pim:8026)

 

Creating 2017 delta area

------------------------------------------------------------------------

r3846 | prf | 2015-05-27 13:07:33 -0500 (Wed, 27 May 2015) | 1 line

Changed paths:

   M /apps/trunk/pim

   D /apps/trunk/pim/session

   M /apps/trunk/pim/tools/cmsource.p

   M /apps/trunk/pim/version

 

From trunk working copy:

 

# pwd

/u/src/pim/42

 

# svn mergeinfo ^/apps/branches/2017/delta/pim

    youngest common ancestor

    |         last full merge

    |         |        tip of branch

    |         |        |         repository path

 

    8026      8066     9155

    |         |        |

       --| |------------         apps/branches/2017/delta/pim

      /        \

     /          \

  -------| |------------         apps/trunk/pim

                       |

                       9154

 

# svn log version -v | more

------------------------------------------------------------------------

r8178 | tja | 2017-04-10 17:47:06 -0500 (Mon, 10 Apr 2017) | 1 line

Changed paths:

   M /apps/trunk/pim

   M /apps/trunk/pim/batchlevel

   M /apps/trunk/pim/svn.ignore.me

   M /apps/trunk/pim/version

 

CM-12814: Update PIM area of trunk to /u/src/pim/41 checkout compatible 41a2 lev

el.

------------------------------------------------------------------------

r8067 | prf | 2017-03-22 12:33:13 -0500 (Wed, 22 Mar 2017) | 1 line

Changed paths:

   M /apps/trunk/pim

   M /apps/trunk/pim/version

 

Updating version

------------------------------------------------------------------------

r3846 | prf | 2015-05-27 13:07:33 -0500 (Wed, 27 May 2015) | 1 line

Changed paths:

   M /apps/trunk/pim

   D /apps/trunk/pim/session

   M /apps/trunk/pim/tools/cmsource.p

   M /apps/trunk/pim/version

 

Thanks,

Todd

 

Todd Armstrong / Senior Software Engineer

Newscyle Commerce

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Branch synch merge from trunk fails with reintegrate error

Stefan Sperling
On Wed, Sep 13, 2017 at 05:25:22PM +0000, Todd Armstrong wrote:
> # svn merge ^/apps/trunk/pim --dry-run
> ^^ related URL path in trunk
> svn: E195016: Reintegrate can only be used if revisions 8027 through 9155 were previously merged from http://source.newscyclesolutions.com/svn/commerce/circulation/apps/branches/2017/delta/pim to the reintegrate source, but this is not the case:
>   apps/trunk/pim
>     Missing ranges: /apps/branches/2017/delta/pim:8027

What happens if you try this 2-URL merge instead?

  svn merge ^/apps/trunk/pim@8027 ^/apps/trunk/pim@9155 --dry-run

Does this command run the sync merge you expect?

> I'm using the command line client (1.8.16) on CentOS 6.8.
> # svn --version
> svn, version 1.8.16 (r1740329)
>    compiled Jul  6 2016, 11:38:59 on x86_64-redhat-linux-gnu

It would be interesting to know if 'svn merge ^/apps/trunk/pim'
with a Subversion 1.9.7 client produces the same 'reintegrate' error.
Perhaps this is a bug which has been fixed in 1.9?

( By the way, based on its compiled date your SVN client is vulnerable to
CVS-2017-9800: https://subversion.apache.org/security/CVE-2017-9800-advisory.txt
Applying the "ssh -q --" workaround mentioned there to your client's
configuration file should be enough to prevent an exploit. )
Reply | Threaded
Open this post in threaded view
|

RE: Branch synch merge from trunk fails with reintegrate error

Todd Armstrong-2
Stefan,

Thanks.  The two URL merge worked - I haven't needed that one before so some reading seems to be in order to understand why of needing to use this- is http://subversion.apache.org/docs/svn-merge.txt  option 3 the best reference?

Also, thanks for the heads up on the security patch.  

Is it possible to install 1.9.x alongside 1.8.x on the same CentOS server where that server is only being used to run command line client working against a remote repository?

# pwd
/u/delta/pim/42

# svn merge ^/apps/trunk/pim@8027 ^/apps/trunk/pim@9155 --dry-run
--- Merging r8028 through r9155 into '.':
U    svn.ignore.me
U    batchlevel
 G   .

# svn merge ^/apps/trunk/pim@8027 ^/apps/trunk/pim@9155
--- Merging r8028 through r9155 into '.':
U    svn.ignore.me
U    batchlevel
 G   .
--- Recording mergeinfo for merge of r8028 through r9155 into '.':
 G   .

-----Original Message-----
From: Stefan Sperling [mailto:[hidden email]]
Sent: Wednesday, September 13, 2017 1:48 PM
To: Todd Armstrong <[hidden email]>
Cc: [hidden email]
Subject: Re: Branch synch merge from trunk fails with reintegrate error

On Wed, Sep 13, 2017 at 05:25:22PM +0000, Todd Armstrong wrote:
> # svn merge ^/apps/trunk/pim --dry-run ^^ related URL path in trunk
> svn: E195016: Reintegrate can only be used if revisions 8027 through 9155 were previously merged from http://source.newscyclesolutions.com/svn/commerce/circulation/apps/branches/2017/delta/pim to the reintegrate source, but this is not the case:
>   apps/trunk/pim
>     Missing ranges: /apps/branches/2017/delta/pim:8027

What happens if you try this 2-URL merge instead?

  svn merge ^/apps/trunk/pim@8027 ^/apps/trunk/pim@9155 --dry-run

Does this command run the sync merge you expect?

> I'm using the command line client (1.8.16) on CentOS 6.8.
> # svn --version
> svn, version 1.8.16 (r1740329)
>    compiled Jul  6 2016, 11:38:59 on x86_64-redhat-linux-gnu

It would be interesting to know if 'svn merge ^/apps/trunk/pim'
with a Subversion 1.9.7 client produces the same 'reintegrate' error.
Perhaps this is a bug which has been fixed in 1.9?

( By the way, based on its compiled date your SVN client is vulnerable to
CVS-2017-9800: https://subversion.apache.org/security/CVE-2017-9800-advisory.txt
Applying the "ssh -q --" workaround mentioned there to your client's configuration file should be enough to prevent an exploit. )
Reply | Threaded
Open this post in threaded view
|

Re: Branch synch merge from trunk fails with reintegrate error

Stefan Sperling
On Wed, Sep 13, 2017 at 09:37:36PM +0000, Todd Armstrong wrote:
> Stefan,
>
> Thanks.  The two URL merge worked - I haven't needed that one before so some reading seems to be in order to understand why of needing to use this- is http://subversion.apache.org/docs/svn-merge.txt  option 3 the best reference?
>

That file contains the verbatim output of 'svn help merge'.
So running that command is the most up-to-date reference :)

Usage option 3 is the most general one. It can be used to emulate all
other usage options. The command I gave you runs a sync merge.

When running a merge with usage option 1 the svn client tries to detect
whether or not to a reintegrate merge is needed.
See http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate

The client makes this decision based on the contents of svn:mergeinfo.
It looks like you found a situation where this heuristic goes wrong.
It's unclear why the client chose the reintegrate merge. It could be
a known bug or an unknown one. I haven't done any further research into
that question because you're using an old client. If this problem is
reproducible with the most recent 1.9 client it's worth invesigating.

> Also, thanks for the heads up on the security patch.  
>
> Is it possible to install 1.9.x alongside 1.8.x on the same CentOS server where that server is only being used to run command line client working against a remote repository?

Yes, a parallel install should be possible.
You could try one or more of the binary distributions linked from here:
http://subversion.apache.org/packages.html#centos
AFAIK the "command-line binaries" from CollabNet install to /opt and
don't overwrite files in /usr/bin. Packages from other vendors may do
the same, but off-hand I am not sure if they do.

Note that you should use a separate working copy with the 1.9 client.
It cannot operate on the working copy created with 1.8. SVN 1.9 will ask
you to upgrade an existing working copy, but upgrading this working copy
will render it unusable by 1.8. So I would suggest you create a fresh
working copy to run the test merge with 1.9.

If you've already committed the result of your 2-URL sync merge, you can
still repeat the same merge with a 1.9 client. Check out a working copy of
the branch at a revision from before the merge was committed, and run the
usage option 1 merge command in that working copy, with a peg revision
appended to cap the merge source revision range.
Say you committed the result of your 2-URL sync merge in r1001, then
something like this should repeat the problematic merge:

  svn co -r 1000 http://source.newscyclesolutions.com/svn/commerce/circulation/apps/branches/2017/delta/pim my-test-wc
  cd my-test-wc
  svn merge ^/apps/trunk/pim@9155

Does this trigger the same "reintegrate" error?
Reply | Threaded
Open this post in threaded view
|

Re: Branch synch merge from trunk fails with reintegrate error

Johan Corveleyn-3
On Thu, Sep 14, 2017 at 11:28 AM, Stefan Sperling <[hidden email]> wrote:
...
> Note that you should use a separate working copy with the 1.9 client.
> It cannot operate on the working copy created with 1.8. SVN 1.9 will ask
> you to upgrade an existing working copy, but upgrading this working copy
> will render it unusable by 1.8. So I would suggest you create a fresh
> working copy to run the test merge with 1.9.

Small correction: 1.8 and 1.9 use the same format of working copy, so
the above paragraph is incorrect. You can use 1.8 and 1.9 svn clients
on the same working copy.

--
Johan