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:s...@elego.de] Sent: Wednesday, September 13, 2017 1:48 PM To: Todd Armstrong <todd.armstr...@newscycle.com> Cc: users@subversion.apache.org 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. )
