Reintegrate can only be used if revisions X through Y were previously merged from <URL> to reintegrate the source, but this is not the case
Asked Answered
C

11

130

Been using SVN branches with Tortoise 1.6. I've been periodically merging the trunk into the branch to keep it up to date.

Today, I thought I'd reintegrate the branch. I chose "Reintegrate a branch" from Tortoise and received the following error message:

Reintegrate can only be used if revisions 4709 through 5019 were previously merged from http://subversion/svn/saxdev/trunk to the reintegrate source, but this is not the case

It then listed around 50 files with descriptions such as this:

Error: branches/qst/kobalt/sax/businessobjects/util/HistoryParent.java

Error: Missing ranges: /trunk/kobalt/sax/businessobjects/util/HistoryParent.java:4709-5018

Revision 5019 is the head revision. Revision 4737 was the revision when I created a branch.

I have this from the log for revision 4737

Action: Added Path: /branches/qst Copy from path: /trunk

To me, that error message says that the branch was not originally from trunk, which isn't true.

Any ideas?

Corder answered 19/1, 2011 at 16:8 Comment(0)
F
145

If you are working on a branch and have been keeping it up to date with others work you might be bemused when you create a working copy of the trunk and attempt to reintegrate your branch if you get a message something like this:

$ svn merge --reintegrate https://server.blah/source/orb/branches/bronze_services
svn: Reintegrate can only be used if revisions 650 through 694 were previously merged from
     https://server.blah/source/orb/trunk to the reintegrate source, but this is not the
     case:
  branches/bronze_services/occl
    Missing ranges: /trunk/occl:650-693

I've seen a number of workarounds on Google but they made me nervous as 'hacks'. To address it I decided to do just what subversion is hinting at in the message. I went back to my branch and explicitly merged the specified revisions:

$ svn merge -r 650:693 https://server.blah/source/orb/trunk
$ svn commit -m 'merged revisions 650:693 from trunk'
    Sending        occl
Committed revision 695.

Once I did this, I was able to return to the working copy of trunk and reintegrate the branch without any problems.

Forefront answered 16/11, 2012 at 3:14 Comment(11)
Nice! "do just what subversion is hinting at in the message". :)Theory
I agree, the more popular answer is tempting, but probably better to fix it correctly. I had to go to the specific problematic file and svn merge it from the trunk.Lamellirostral
This worked great for me. The main trick was that Tortoise wasn't telling me the problem revision. After upgrading my command line svn client I was able to get it to give me a message like you have, and then was able to merge the problem revision and go back to the trunk.Roadhouse
I also had this problem with TortoiseSVN 1.7.5 - returning to my branch and merging in all the revisions from /trunk which it told me were missing worked, eventually. There was the odd conflict, but nothing terribly major. +1Tower
I agree that this is the right solution, but unfortunately it didn't work for me and I was not able to determine why. However, it seems like the solution isn't quite right. If revisions 650:693 are missing, shouldn't the merge command be -r 649:693? Or does the error message automatically account for the starting point?Elmiraelmo
This didn't work for me because the listed "missing" merges had already been done in the branch (reintegrate source).Wilburwilburn
What is the meaning of a merge without a destination ?Figure
While this answer sounds reasonable, it did not work for me. I kept getting the same error messages. What helped, was to remove the svn:mergeinfo properties from the listed files, just like the accepted answer is suggesting.Conformist
Is it correct to merge the trunk and not the branch?Cathedral
I get such message Missing ranges: /branches/development:11266,11270-11271,... (about 200 more characters) what would you suggest me to do?Nerynesbit
In my case there was a revision on the trunk that wasn't in the dev branch: it was just a row in a file which I had deleted manually on the two branches in parallel, so when I had merged sync from trunk to dev, that revision was not taken into account by SVN since the files were identical! To get rid of the error message, I had to revert the manual deletion on dev, than merge all again from trunk, and from then on, the merge all from dev to trunk worked fine.Sand
W
87

[[ Although my solution has worked for me in the past, it can lead to improper results with modern SVN clients. In our case the merge errors seemed to be byproducts of automations that were confusing our SVN history and not real activity. I'm leaving this here for posterity but please consider the accepted answer instead. ]]

The solution for me was to remove any svn:mergeinfo properties that somehow get attached to individual files in the hierarchy.

svn merge --reintegrate svn+ssh://svn/usr/local/svn/repos/all/trunk 
svn: Reintegrate can only be used if revisions 18765 through 18921 were
    previously merged from svn+ssh://svn/usr/local/svn/repos/all/trunk to the
    reintegrate source, but this is not the case:
trunk/proj/src/main/java/com/foo/furniture.java
Missing ranges: /trunk/proj/src/main/java/com/foo/furniture.java:18765-18920

To find the files with mergeinfo information you can do:

cd ~/svn/branches/2.7
svn propget -R svn:mergeinfo .

Then you can remove the mergeinfo properties:

svn propdel svn:mergeinfo proj/src/main/java/com/foo/furniture.java ...
svn commit -m 'removed mergeinfo' proj/src/main/java/com/foo/furniture.java ...

After I completed this, my merge executed fine.

Wira answered 19/7, 2011 at 17:30 Comment(11)
This really helped me solve my issue but mine was due to merging a revision from a child folder rather doing this on the root folder. My issue was - I had performed the merge but the root folder hadn't recognised that the merge had happened, this meant that I had to manually update the mergeinfo prop with the missing revision numbers. NOTE I could only do this because there were no other files changes for the revision and will cause unexpected behaviour if other files need to be merged - you will need to re-merge the revisions if this is the case.Postgraduate
+1 This worked for me!! Deleting the merge-info on the file in question fixed it!Stead
Removing mergeinfo from all but the branch root worked for me, although not sure how I got into such a mess in the first place as have been merging trunk to the branch periodically :/Embroidery
In TortoiseSVN, you can right click the file, select "TortoiseSVN" --> "Properties" and Delete the svn:mergeinfo property.Globoid
@StephenKennedy You might be running into the problem of reusing a branch that's already been reintegrated. If so check out the last section of svnbook.red-bean.com/en/1.7/… starting with "Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work."Mccarthy
+1. You don't need to delete all the mergeinfos; just the ones that have missing ranges. See my answer for a way to delete just the problem mergeinfos by filtering the TortoiseSVN error output.Deep
This worked for me. i had a file where the same change was committed to trunk and branch, the file was OK but its folder was reporting this missing range on the revision where the trunk was changed. deleting the props on the folder fixed it.Gally
-1. You should not be removing mergeinfo properties unless you are really sure about what you are doing. Lots of people may read this, delete these properties, and inadvertently introduce other problems. Paul Whipp has a better answer.Loquitur
I had so many mergeinfos that removing them all manually was too fiddly, so I used this shortcut to delete all the mergeinfos except the root directory's: cd ~/svn/branches/2.7 svn propdel svn:mergeinfo . -R svn revert .Baleful
Deleting mergeinfos has really bad side effects in my experience. It is not a real merge if you do that, we could say. As a result, affected files' merge history stays distorted forever, and resolving conflicts becomes more challenging.Medius
I tried the top answer, but without the step to delete mergeinfo, it did not work. This answer worked quite well.Filipe
D
16

If you try to reintegrate your branch to trunk and you see errors like this from TortoiseSVN:

Merge reintegrate test only failed!: "Reintegrate can only be used if some revisions were previously merged from trunk, but this is not the case"

Click on the error text and press CTRL + A, CTRL + C to copy all the text.

Paste the text into the here-string of this PowerShell script:

@"
Command: Reintegrate merge http://svn.cloudcorp.com/branches/myproject into C:\Users\iain\Documents\Repositories\CloudCorp\trunk  
Error: Reintegrate can only be used if revisions 18089 through 18612 were previously  
Error:  merged from http://svn.corp.skyscanner.local/svn/SkyScannerDatabase/trunk to  
Error:  the reintegrate source, but this is not the case:  
Error:    
Error:  branches/myproject/userdata/usermanagementservice  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/usermanagementservice:18365,18404  
Error:    
Error:  branches/myproject/userdata/auto_create_db.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/auto_create_db.sql:18406  
Error:   
Error:    
Error:  branches/myproject/userdata/create_audit_tables_triggers_uds.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/create_audit_tables_triggers_uds.sql:18406  
"@ -split "`n" |
? { $_ -match ('Error: +branches') } |
% { $_.Substring($_.IndexOf('userdata')) } |
% { "svn propdel svn:mergeinfo $_" }

The script extracts the relative paths of files with problem mergeinfo and outputs a list of commands to fix each one.

You may have to change the 'userdata' value to suit your repository structure.

Execute the script to output the commands you need to remove the problem mergeinfos.

In this example, the script would produce this output:

svn propdel svn:mergeinfo userdata/usermanagementservice  
svn propdel svn:mergeinfo userdata/auto_create_db.sql  
svn propdel svn:mergeinfo userdata/create_audit_tables_triggers_uds.sql  

At the command prompt you can navigate to the branch base (myproject) and execute the commands to delete the problem mergeinfos.

You should see output like this:

property 'svn:mergeinfo' deleted from 'userdata\usermanagementservice'.
property 'svn:mergeinfo' deleted from 'userdata\auto_create_db.sql'.
property 'svn:mergeinfo' deleted from 'userdata\create_audit_tables_triggers_uds.sql'.

As in Gray's answer, now you should commit the changes to the branch and try to reintegrate again. This time it should work!

Deep answered 19/7, 2013 at 16:21 Comment(7)
Long before reintegrating I did merge (not reintegrate) some changes to trunk from my branch because I accidentally committed to my branch when I meant to commit to trunk. Could it be the reason behind these reintegrate errors?Deep
That's exactly what seems to have caused this problem in my case. Thanks for taking the time to write the script!Wilburwilburn
@Wilburwilburn Glad you found it helpful. Did you need to replace the literal space with a \s+ to make it work for you?Deep
Sort of; it was more the + that was needed for it to work for me. In my case, some lines had two spaces and others had three, so support for variable numbers of spaces was needed. I'm not sure why I changed the space to a \s; that probably wasn't needed, so sorry for that part!Wilburwilburn
@Wilburwilburn No worries, but I'll change it back to a literal space for now until TortoiseSVN starts mixing it up with tabs or whatever :-) I've left the + since it was useful for you.Deep
Fair enough; sorry for making the change without asking! I was in a hurry, but I didn't want anyone else to have to change the script to get it working.Wilburwilburn
@Wilburwilburn I'm only being so pedantic because I've encountered subtle bugs in some regex engines with the behavior of \s versus literal space. :-)Deep
C
12

Actually I fixed it using the "merge two different branches" option to merge the trunk and the branch into my working copy. Then I committed that to the trunk.

Marvellous

Corder answered 19/1, 2011 at 16:37 Comment(6)
This answer doesn't really explain what you did. No examples, not even a link to the requisite section of the manual.Southworth
In hindsight, no it doesn't. However, as this was my own answer on the same day as the question, it was the best answer for a few months. I'd like to presume it makes sense if you still use Tortoise SVN 1.6 though. I have accepted Gray's answer as the accepted answer now instead.Corder
Example: svn merge ^/tags/w.x ^/tags/y.z . The reintegrate error popped up for me when using 1.8 and merging into the trunk where the merge source had had a specific revision previously merged into it from the trunk. 1.8 appeared to decide that a reintegrate merge was being attempted, which it wasn't. A dry-run merge with 1.6 would work fine, but the two URL merge fits too.Colure
The precise scenario that failed with 1.8 was copying a tag from some revisions back for a patch release, cherry picking a change from the trunk to backport by a merge into the patched tag, making a further change to the patched tag, and merging that back into the trunk. The changes between the base tag and the patched version are what need to be merged back to the trunk, and a 2 URL merge works a treat for that.Colure
I should have read this answer before spending 3 days trying to understand what was going on. I still don't understand why I have had this problem but suspect the comment from @Colure is the reason - and now things are working I'm not going to look any further...Cogitation
@DaveRlz Not sure if this relates to what I commented on, but even in 1,9, I found that merging into specific items rather than an entire WC can cause faults in the svn:mergeinfo property handling affecting reintegration merges in particular. Spent hours recently using --record-only and some manual mergeinfo edits to elide mergeinfo successfully. Some mergeinfo properties in the trunk recorded merges from the trunk, i.e. to itself. So mergeinfo handling is still faulty unfortunately. I've learnt where care is needed and how to work around it though.Colure
A
7

Something that worked for me in tortoise SVN: instead of merging all revisions from branch, choose specific range and manually select all your revisions from the branch.

Abjure answered 22/8, 2017 at 22:23 Comment(1)
Thank you for such a basic idea. Of all the answers, this was not only the least complicated, but it was the only one that worked for me.Spindry
H
3

Just do as SVN is telling you.

  1. Merge the branch from the Reversion that SVN is telling you
  2. Reintegrate from Branch to trunk
Hamadryad answered 9/12, 2013 at 12:28 Comment(1)
Didn't work for me. The changes already existed in the branch. Your instructions look like they should work for some cases, but they seem to be based on an assumption, so they don't seem universal.Wilburwilburn
S
2

I got this error after using a partial checkout of a branch. I was keeping the branch up to date with the trunk but the trunk revisions for parts of the branch that were not checked out were of course not being updated. The fix was to do a full checkout of the branch and then merge in all of the trunk changes. After committing these to the branch I could merge the branch to the trunk successfully.

Saudra answered 26/4, 2019 at 11:13 Comment(0)
L
1

See also my answer here for my experience with a similar case. I'm not sure if this is the source of your problem, but it does look like Subversion 1.8 has problems with the mergeinfo when two changes cancel each other.

Lefty answered 26/11, 2013 at 23:32 Comment(0)
S
1

Got this issue on

  • TortoiseSVN 1.9.7, Build 27907 - 64 Bit , 2017/08/08 19:34:38
  • Subversion 1.9.7, -release
  • apr 1.5.2
  • apr-util 1.5.4
  • serf 1.3.9
  • OpenSSL 1.0.2l 25 May 2017
  • zlib 1.2.8
  • SQLite 3.14.1

right click on the branch where you wish to merge (but getting this message) and select the option "update to revision" and then on the dialog which opens (screenshot below) select those revisions and click ok - once all previous revisions are merged, you wouldn't get this message

enter image description here

Adding this here to help someone who is using Tortoise SVN

Steepen answered 21/11, 2019 at 4:55 Comment(0)
G
0

I ran into this issue. I did an SVN log on my branch to find were I had merged trunk to my branch.

I noted all the revisions.

I then did the merge of my branch to trunk by specifying the revisions manually. I specified all ranges to exclude the revisions were I merged trunk. I manage to get my branch merged.

I had to do some reverts on mergeinfo, but I got my code merged.

I immediately deleted my branch.

Giustino answered 13/4, 2015 at 19:38 Comment(0)
B
-1

I know this is an old post, but I was struggling to solve this issue as well until I found out that the files listed in the error message have SVN property issue.

I did right click on the troubled files: TortoiseSVN > Properties, and found that the file had two svn:mergeinfo, and one of them didn't have inherited from data. So I removed that mergeinfo.

I use TortoiseSVN 1.12.2, Build 28653 - 64 Bit.

Balduin answered 10/9, 2019 at 3:50 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.