From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103767 invoked by alias); 9 Jul 2018 19:40:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 103754 invoked by uid 89); 9 Jul 2018 19:40:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=examination, familar, tip, pin X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 19:40:09 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C59C130832D3; Mon, 9 Jul 2018 19:40:07 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-9.rdu2.redhat.com [10.10.112.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id A2CC25D750; Mon, 9 Jul 2018 19:40:06 +0000 (UTC) Subject: Re: Repo conversion troubles. To: "Eric S. Raymond" , GCC Development , fallenpegasus@gmail.com References: <20180709191911.648443A4AA7@snark.thyrsus.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Mon, 09 Jul 2018 19:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180709191911.648443A4AA7@snark.thyrsus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00136.txt.bz2 On 07/09/2018 01:19 PM, Eric S. Raymond wrote: > Last time I did a comparison between SVN head and the git conversion > tip they matched exactly. This time I have mismatches in the following > files. > > libtool.m4 > libvtv/ChangeLog > libvtv/configure > libvtv/testsuite/lib/libvtv.exp > ltmain.sh > lto-plugin/ChangeLog > lto-plugin/configure > lto-plugin/lto-plugin.c > MAINTAINERS > maintainer-scripts/ChangeLog > maintainer-scripts/crontab > maintainer-scripts/gcc_release > Makefile.def > Makefile.in > Makefile.tpl > zlib/configure > zlib/configure.ac > > Now I'll explain what this means and why it's a serious problem. [ ... ] That's weird -- let's take maintainer-scripts/crontab as our victim. That file (according to the git mirror) has only changed on the trunk 3 times in the last year. They're all changes from Jakub and none look unusual at all. Just trivial looking updates. libvtv.exp is another interesting file. It changed twice in early May of this year. Prior to that it hadn't changed since 2015. [ ... ] > > 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'm assuming that it's only work that merges onto the trunk that's potentially problematical here. > > So...does that list of changed files look familar to anyone? If we can > identify the revision number of the bad commit, the odds of being able > to unscramble this mess go way up. They still aren't good, not when > merely loading the repository for examination takes over four hours, > but they would way better than if I were starting from zero. They're familiar only in the sense that I know what those files are :-) Jeff