On Tue, Aug 04, 2020 at 06:37:07PM +0000, Jacob Weber wrote:
> Hi there. I'm doing a merge which seems to be doing a very long-running operation (over an hour so far) when it gets to the "Searching tree conflict details" step. I'm wondering if there's any way to avoid this.
>
> I'm merging from a branch X where a directory was removed, into a branch Y where that same directory was removed. In each case, the removal was actually done as part of a reintegrate merge from a different branch.
>
> I can reproduce this every time I revert and restart the merge. Unfortunately I can't share the content of my repository.
>
> The output is something like this:
>
> $ cd branchY
> $ svn update
> $ svn merge ^/branchX
> --- Recording mergeinfo for merge of r10000 through r20000 into '.':
> U .
> --- Merging r20001 through r20100 into '.':
> A foo
> A bar
> G .
> --- Recording mergeinfo for merge of r20001 through r20100 into '.':
> G .
> Summary of conflicts:
> Text conflicts: 2
> Tree conflicts: 7
The above per-path output shows no new conflicts. I suppose you were actually
seeing lines such as "C foo" somewhere, and they are just missing from
your example?
> Searching tree conflict details for 'path/to/conflict/dir' in repository:
> Checking r9000...
>
> At this point it slowly starts decreasing the revision after "Checking". But it seems to be going through my entire repository history, which will take forever.
>
> Is there any way to avoid this?
Yes. The option: --accept=postpone
for svn merge will bypass the conflict resolver and flag a tree conflict
in the working copy.
This conflict still needs to be resolved before the merge result can be
committed. Note that 'svn resolve' will try to scan history again, so you
will need to use some non-interactive variant of this command.
If one of the --accept option paremeters achieve the result you want to
resolve to, then you could use --accept with a suitable parameter (see
the output of 'svn help resolve' for a list).
Otherwise, use this command to simply clear the conflict marker:
svn resolve --accept=working path/to/conflict/dir
And then resolve the actual conflict manually as required.
> Mac OS 10.14.6
> SVN client 1.14.0, compiled Jul 4 2020, 20:57:11 on x86_64-apple-darwin18.7.0
> SVN server 1.8.13
Some conflicts may be avoided if the server was upgraded to SVN 1.10 or later.
Newer servers can help with avoiding some tree conflicts.
See for example, see https://svn.apache.org/r1760570 -- this bug should
affect you since it was first fixed in 1.9.5. Though I doubt it is related
to your problem at hand since it looks like your conflict is on a directory
rather than a file.
Unfortunately, deep history crawls cannot always be avoided. Since information
shown by the resolver can save people a lot of time trying to figure out what
happened, it is considered acceptable that the resolver may take a while to
obtain this information.
Of course, an hour is outside of this acceptable scope. There could also be
a bug to fix in this case. We've found and fixed similar problems before,
for example here: https://svn.apache.org/r1839662 (this particular problem
does *not* affect you since are using a 1.14 client).
But in order to figure this out we'd need a lot more information from you.
Ideally, a script which starts off with an empty repository, populates it
(with deep history if necessary), and then runs a series of SVN commands
which ends in a merge that triggers the problem.
Cheers,
Stefan
Received on 2020-08-04 22:52:02 CEST