Thanks Stefan. --accept=postpone sounds like just what I need.
I ended up discovering that if I committed an empty directory in the location of the conflict, it would skip the deep history search, and show a different tree conflict right away. So that got me out of waiting. But I'll try --accept=postpone next time.
You're right — I removed most of the real merge results from my example.
I don't think I'm going to be able to create a reproducible repository, unfortunately (it's proprietary).
Jacob
> On Aug 4, 2020, at 1:51 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> 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 23:12:17 CEST