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 <s...@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 >
