[
https://issues.apache.org/jira/browse/SVN-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837638#comment-15837638
]
Stefan Sperling commented on SVN-4582:
--------------------------------------
Do we still see a cause for action here or can this ticket be closed?
This issue is still open, which leaves the impression that we were going to do
something about being unable to run the reintegrate merge if invalid mergeinfo
is present. But I don't see a way of fixing that without negatively affecting
the precondition checks of reintegrate for other use cases.
As Bert pointed out, the problematic mergeinfo may not be empty but may simply
be containing misinformation. How could we detect such mergeinfo errors
reliably? In general, the program cannot know whether mergeinfo is telling lies
or the truth.
As a workaround, an equivalent 2-URL merge can be used to reintegrate the
branch, instead of invoking the reintegrate merge directly.
As newer client versions spread out in the ecosystem, this problem should get
less and less relevant.
> reintegrate complains about missing ranges from node unrelated to branch
> ------------------------------------------------------------------------
>
> Key: SVN-4582
> URL: https://issues.apache.org/jira/browse/SVN-4582
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_client
> Affects Versions: trunk
> Reporter: Stefan Sperling
> Fix For: ---
>
> Attachments: 1_issue4582.sh
>
>
> {noformat:nopanel=true}
> If two directories with the same path are added on trunk and a branch of
> trunk,
> it can happen that 'svn merge' later refuses to reintegrate the branch to
> trunk:
> svn: E195016: Reintegrate can only be used if revisions 2 through 5 were
> previously merged from file:///home/stsp/svn/reint-missing-ranges/repos/trunk
> to the reintegrate source, but this is not the case:
> branch/dir
> Missing ranges: /trunk/dir:3
> In this case, branch/dir and trunk/dir do not share node ancestry.
> A sync merge was run just before the reintegrate merge. This merge raised a
> tree
> conflict at 'dir' which was resolved to use the branch's version of 'dir' by
> running 'svn resolved --accept working', which is the most likely action an
> average user would try in this situation (especially since our current
> conflict
> resolver does not really present any useful alternative, which is a separate
> and
> larger issue in itself).
> Running another sync merge does not resolve the problem since there is in fact
> nothing left to merge.
> Instead, the reintegrate merge should proceed and raise an add vs add tree
> conflict. Interestingly, this is exactly what a 2-URL merge effecting the same
> reintegrate operation does! So it would seem the pre-condition checks run
> before
> a reintegrate merge are getting confused. I suppose if the pre-condition
> checks
> were fixed the merge would "just work" as expected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
