On 07/09/2018 01:57 PM, Eric S. Raymond wrote: > Jeff Law <l...@redhat.com>: >>> There are brute-force ways to pin down such malformations, but none of >>> them are practical at the huge scale of this repository. The main >>> problem here wouldn't reposurgeon itself but the fact that Subversion >>> checkouts on a repo this large are very slow. I've seen a single one >>> take 12 hours; an attempt at a whole bisection run to pin down the >>> divergence point on trunk would therefore probably cost log2 of the >>> commit length times that, or about 18 days. >> >> I'm not aware of any such merges, but any that occurred most likely >> happened after mid-April when the trunk was re-opened for development. > > I agree it can't have been earlier than that, or I'd have hit this rock > sooner. I'd bet on the problem having arisen within the last six weeks. > >> I'm assuming that it's only work that merges onto the trunk that's >> potentially problematical here. > > Yes. It is possible there are also content mismatches on branches - I > haven't run that check yet, it takes an absurd amount of time to complete - > - but not much point in worrying about that if we can't get trunk right. > > I'm pretty certain things were still good at r256000. I've started that > check running. Not expecting results in less than twelve hours. r256000 would be roughly Christmas 2017. I'd be very surprised if any merges to the trunk happened between that point and early April. We're essentially in regression bugfixes only during that timeframe. Not a time for branch->trunk merging :-)
jeff
