Branch synch merge from trunk fails with reintegrate error

[Todd Armstrong]

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<http://newscycle.com/solutions/circulation-subscription-management-system/#_SubscriptionLink>

[Stefan Sperling]

Post by Todd Armstrong
# svn merge ^/apps/trunk/pim --dry-run
^^ related URL path in trunk
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/***@8027 ^/apps/trunk/***@9155 --dry-run

Does this command run the sync merge you expect?

Post by Todd Armstrong
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. )

[Todd Armstrong]

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/***@8027 ^/apps/trunk/***@9155 --dry-run
--- Merging r8028 through r9155 into '.':
U svn.ignore.me
U batchlevel
G .

# svn merge ^/apps/trunk/***@8027 ^/apps/trunk/***@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:***@elego.de]
Sent: Wednesday, September 13, 2017 1:48 PM
To: Todd Armstrong <***@Newscycle.com>
Cc: ***@subversion.apache.org
Subject: Re: Branch synch merge from trunk fails with reintegrate error

# svn merge ^/apps/trunk/pim --dry-run ^^ related URL path in trunk
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/***@8027 ^/apps/trunk/***@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. )

[Stefan Sperling]

Post by Todd Armstrong
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.

Post by Todd Armstrong
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/***@9155

Does this trigger the same "reintegrate" error?

[Johan Corveleyn]

On Thu, Sep 14, 2017 at 11:28 AM, Stefan Sperling <***@elego.de> wrote:
...

Post by Stefan Sperling
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.