From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105674 invoked by alias); 6 Dec 2019 20:43:20 -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 105666 invoked by uid 89); 6 Dec 2019 20:43:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=perspective, Experience, talk, management X-HELO: esa4.mentor.iphmx.com Received: from esa4.mentor.iphmx.com (HELO esa4.mentor.iphmx.com) (68.232.137.252) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2019 20:43:19 +0000 IronPort-SDR: Gw7ZmKq0EUVTb2Txmy/LZpfBKtA5EP7nhd4ih7NHlNuklzxF5N5YXeDX6zNwtoPg7ywx/CIt78 LhvIKmoa7GNPIQOpDR13oWxrP0r5DbaTJiPB5kuAVHsDA1lut+6E9rlvMyHHAIlj1azsq+HhmF wggZ7+NyCSOuO4F7GqqVswNt44239S/lz0a2CvRmtrH4/YzB2K7/DdpKVhjwDRnAkPW5mT6rPo +50SNqnf93ILj/RN5AKFgZZWRQP+VjopfUlcQgOn9voX+wMTXSYo9TVra3DOnfJ9HdTs9B/Pul hGE= Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 06 Dec 2019 12:43:17 -0800 IronPort-SDR: Sb7FWxa7pt298vVK1bHJY9DBYwfYUM4p3dFia4FHdlCryAP1tHvIcnYXqE+xq8D8Sg1dnG50hF TpvLDzDENyyawa8yXt/nNAqzw7d+hlAORDrpcTPiiqN9X7+7R2+Yp/3P6VdajwgL4B+xFwZRXP rCyw0UltOy0FydgepyHkbiCYLogbX37czlpbeP+49XfmHJ1aMG7kyyBAWJ5KwKuibD3BrTkOdN Q6+1PsJg0oeI+TMfE2endu0pMhKga0DCDVQ5FkrNuOJ9i2KGbXCB8Um8/MNBrdzcT/7X1Nv0IO 0Fw= Subject: Re: Proposal for the transition timetable for the move to GIT To: , Richard Biener CC: Maxim Kuvyrkov , "Richard Earnshaw (lists)" , References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <20191206172111.GA116282@thyrsus.com> <0485C474-1B83-42C2-AEAD-7CA252C6CC12@gmail.com> <20191206194604.GA115432@thyrsus.com> From: Sandra Loosemore Message-ID: <1f25d0b5-446e-bce7-804a-41051e1934ae@codesourcery.com> Date: Fri, 06 Dec 2019 20:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191206194604.GA115432@thyrsus.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-Path: sandra@codesourcery.com X-SW-Source: 2019-12/txt/msg00113.txt.bz2 On 12/6/19 12:46 PM, Eric S. Raymond wrote: > Richard Biener : >> To me, looking from the outside, the talks about reposurgeon doing damage and a rewrite (in the last minute) would fix it doesn't make a trustworthy appearance either ;) > > *shrug* Hard problems are hard. > > Every time I do a conversion that is at a record size I have to > rebuild parts of the analyzer, because the problem domain is seriously > gnarly. I'm having to rebuild more than usual this time because the > GCC repo is a monster that stresses the analyzer in particularly > unusual ways. > > Reposurgeon has been used for several major conversions, including groff and Emacs. > I don't mean to be nasty to Maxim, but I have not yet seen *anybody* who thought they > could get the job done with ad-hoc scripts turn out to be correct. Unfortunately, > the costs of failure are often well-hidden problems in the converted history > that people trip over months and years later. > > Experience matters at this. So does staying away from tools like git-svn that > are known to be bad. I have nothing useful to contribute regarding the actual mechanics of the repository conversion (I'm a total dummy about the internals of both git and svn and stick with only the most basic usages in my daily work), but from a software engineering and project management perspective.... I'm also put off by the talk of having to do last-minute rewrites of a massively complex project. [Insert image of prehistoric animals trapped in tar pit here.] Shouldn't it be possible to *test* whether Maxim's git-svn conversion is correct, e.g. by diffing the git and svn versions at appropriate places in the history, or comparing revision histories of each file at branch tips, or something like that? Instead of just asserting that it's full of bugs, without any evidence either way? I'd expect that the same testing would need to be performed on the reposurgeon version in order to have any confidence that it is any less buggy. Do we have any volunteers who could independently work on QA of whatever git repository we end up with? -Sandra