From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117235 invoked by alias); 9 Dec 2019 18:19:38 -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 117227 invoked by uid 89); 9 Dec 2019 18:19:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=validation, risks, intend, raymond X-HELO: esa1.mentor.iphmx.com Received: from esa1.mentor.iphmx.com (HELO esa1.mentor.iphmx.com) (68.232.129.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Dec 2019 18:19:37 +0000 IronPort-SDR: Ld2SVbUQHvbkgZtV2OJK7kGwsaAnB3/FJww7QXHdnt2gPOCwVwJWzfMPO90j1t07F53l48X8qu AltbXoWR5PDUexAJC/X6QloY4NyC2ExhOVtmMq0xNoItWWb0nNvz2IPPLr3NNM/fce43FvMRDN Tc0nVPsh3NUTJCRP5dPSbodMQEwLdVJc3ErFTh04qt2i++BscgXubCjdAS5jqDgLzqiiisAkAO tBcGo6M8F4OwAULKNDjBMY679LP7IFUB6oTEdke5hbInO/dwp/cB2xtmpTISeQgEtqKhc/B20Q J24= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 09 Dec 2019 10:19:35 -0800 IronPort-SDR: WxmPl+hs7oiBhVIW/kEoguYkEC8L/exiDq7JPsiJmhkVNv52l9BEdZh2IBbIdBvZAvVfTC7KSV rljkZFqSMkqITOEbHltToenMyrk1kVPRLIOhQv5Q1e3zYn1vf+JFvd+mPyX5oUC1B8E+gqvHxr TYCZccmGSW9kh3uaUx3rkSFc62LMSU9i357oeJ6J8KpFwVqjTF+lsz0g8yJQsv8CmigHZGM+gY jEXgHvnBZG8NDwquhMoFoHf9eTIgO7neZ96yFGJmVq+KvDS29NHiJSDehyIOdwMcQlxPVFPNlu Hfo= Date: Mon, 09 Dec 2019 18:19:00 -0000 From: Joseph Myers To: "Eric S. Raymond" CC: Richard Biener , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , Subject: Re: Proposal for the transition timetable for the move to GIT In-Reply-To: <20191206194604.GA115432@thyrsus.com> Message-ID: 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> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-12/txt/msg00137.txt.bz2 On Fri, 6 Dec 2019, Eric S. Raymond wrote: > 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. I think the ad hoc script is the risk factor here as much as the fact that the ad hoc script makes limited use of git-svn. For any conversion we're clearly going to need to run various validation (comparing properties of the converted repository, such as contents at branch tips, with expected values of those properties based on the SVN repository) and fix issues shown up by that validation. reposurgeon has its own tools for such validation; I also intend to write some validation scripts myself. And clearly we need to fix issues shown up by such validation - that's what various recent reposurgeon issues Richard and I have reported are about, fixing the most obvious issues that show up, which in turn will enable running more detailed validation. The main risks are about issues that are less obvious in validation and so don't get fixed in that process. There, if you're using an ad hoc script, the risks are essentially unknown. But using a known conversion tool with an extensive testsuite, such as reposurgeon, gives confidence based on reposurgeon passing its own testsuite (once the SVN dump reader rewrite does so) that a wide range of potential conversion bugs, that might appear without showing up in the kinds of validation people try, are less likely because of all the regression tests for conversion issues seen in past conversions. When using an ad hoc script specific to one conversion you lose that confidence that comes from a conversion tool having been used in previous conversions and having tests to ensure bugs found in those conversions don't come back. I think we should fix whatever the remaining relevant bugs are in reposurgeon and do the conversion with reposurgeon being used to read and convert the SVN history and do any desired surgical operations on it. Ad hoc scripts identifying specific proposed local changes to the repository content, such as the proposed commit message improvements from Richard or my branch parent fixes, to be performed with reposurgeon, seem a lot safer than ad hoc code doing the conversion itself. And for validation, the more validation scripts people come up with the better. If anyone has or wishes to write custom scripts to analyze the SVN repository branch structure and turn that into verifiable assertions about what a git conversion should look like, rather than into directly generating a git repository or doing surgery on history, that helps us check a reposurgeon-converted repository in areas that might be problematic - and in that case it's OK for the custom script to have unknown bugs because issues it shows up are just pointing out places where the converted repository needs checking more carefully to decide whether there is a conversion bug or not. -- Joseph S. Myers joseph@codesourcery.com