Reintegrate merge claims missing revisions with numbers lying before branch creation

0
votes

During SVN reintegrate-merge (TortoiseSVN/Windows), I get the following errors:

Command: Auto-merge /svn/branches/branchX into C:\MyRepoFolder
Error: Reintegrate can only be used if revisions 59635 through 65976 were previously
Error: merged from svn/trunk to the reintegrate source, but this is not the case:
Error:
Error: svn/branches/branchX/Applications/.../source/someFile.cpp
Error:
Error: Missing ranges:
Error: /trunk/Applications/.../source/someFile.cpp:43835,43956,43965,...
...
(and so on)
...

The branch was created at Rev 59635, why are are older ranges around 43835 missing when the branch was created from trunk in the past? Can someone please tell me how this is possible and how to solve the issue?

I have already tried many things including:

  • trunk -> branch: auto merge of problematic revisions
  • trunk -> branch: record only merge of these old revisions
  • adding revisions to corresponding merge-info

The latter did work, but doing this manually is very exhaustive since the list is extremely long (I have listed only a fraction here). All other attempts did not work. But I don't think that manually adding the the revisions to the corresponding merge-infos is the best solution here. Maybe I can write a script that does it automatically. I would be very interested in alternatives? I can't imagine that there is no better solution here.

1
svntortoisesvn
You can easily mark all revisions as merged with a) remove all mergeinfo from subpaths (execute in branch root svn pd svn:mergeinfo * -R) and then b) modify mergeinfo on root to something like 1-999999. But of course it is better to understand real cause of problem... – Sergey Azarkevich
@Sergey Azarkevich: What are the implications of doing that? Does this affect future merges to the trunk? – Thomas

1 Answers

1
votes

I suspect this issue is a combination of different svn versions used, together with subtree merges. The first alone is not a problem at all, but subtree merges are a prime source of constant headaches.

My suggestion: find out if the maintainers of the repo have a policy on subtree merges, ie, if they explicitly allow or disallow merging not just at the root level of a branch but also individual files or subfolders.

If they allow it: sorry, you're screwed. Try to find the people who did the subtree merges and ask them if they still use this subtree merge info (and what they were thinking when they did it in the first place).

If subtree merges are not allowed (or you are the sole maintainer of the repo), just delete all subtree merge information but preserve it at the root level. You can do this eg by going to the root of your clean branch working copy and executing 

svn pd svn:mergeinfo . -R
svn revert .

The first command will delete all merge information recursively (including the bad stuff), the second will restore the useful and necessary merge information at the branch root. Before proceeding, make sure you did not change anything else (if you did it right, svn st should show a bunch of files/folders with an M only in the second column, indicating that only properties were changed) and commit. Afterwards, reintegration should work again.

Please note: the svn:mergeinfo property is "sticky", so once you merge the trunk again to your branch (or reintegrate other branches with subtree merge information), the bad merge info properties will reappear. To really get rid of them, you need to delete the subtree merge information in the trunk itself and force all users to do the same for their branches before reintegrating back to trunk. We had a similar issue about a year ago and what we did was to check out the whole branches/ subfolder and run a script to delete all unnecessary merge information from all branches simultaneously.