Hello guys,
I'm having a trouble with SVN trying to prevent me from merging my
stable (release) branch back to trunk (dev) branch. I'd like to check
with you whether we need to change our merge practices to avoid this
from happening or whether this should be considered as a bug.
How this situation occurred:
trunk-3-3 --B-----------M
\ \
trunk-3-4 B--B---P----M---!
\ \ /
rel-3-4-3 B---P----!
Branch trunk-3-4 was created from branch trunk-3-3 (B), and rel-3-4-3
was created from trunk-3-4 (B). Then one of the developers backported
(cherry-pick) a change from trunk-3-4 to rel-3-4-3 (P). Finally,
trunk-3-3 was merged to trunk-3-4 (M).
Now, I'd like to merge rel-3-4-3 back to trunk-3-4 with latest SVN
(1.8.4) - denoted with ! character. I get the following error message:
svn: E195016: Reintegrate can only be used if revisions 33877 through
34252 were previously merged from https://.../trunk-3-4 to the
reintegrate source, but this is not the case:
/branches/release-3-4-3
Missing ranges: /trunk-3-4:34008
Commit 34008 in trunk-3-4 is the one denoted with M - the trunk-3-3 to
trunk-3-4 merge commit.
What I see here is that SVN (wrongly?) assumed that it needs to do a
reintegrate merge - apparently because of the P commit that changed
mergeinfo in branch rel-3-4-3 - because the developer used svn merge to
do the cherry-pick.
So now when merging rel-3-4-3 back to trunk-3-4 SVN tries to do
reintegrate merge while I only need it to do regular merge.
I see a couple of options here: pick revisions that I want to merge
manually or find some other way to force SVN not to use reintegrate.
I can also edit the mergeinfo in rel-3-4-3, delete trunk-3-4 entry in it
introduced with the P commit.
Question is, how do I prevent this situation from happening in the
future? Should I instruct the developers to stop using svn merge for
cherry-picking? Is there some other ways to enforce that reintegrate
won't be used by the auto-merge?
Jan Raszyk
