From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102270 invoked by alias); 11 Dec 2019 14:40:30 -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 102250 invoked by uid 89); 11 Dec 2019 14:40:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=mistakes, Emacs, surgery, Proposal X-HELO: mail-lf1-f66.google.com Received: from mail-lf1-f66.google.com (HELO mail-lf1-f66.google.com) (209.85.167.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Dec 2019 14:40:28 +0000 Received: by mail-lf1-f66.google.com with SMTP id m30so16858130lfp.8 for ; Wed, 11 Dec 2019 06:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7KVndnirI75BciCQlcESZNiAfJnN828KejtXgoA4jHs=; b=mjwziPvtgqoN6BJ4HHYXS5ozme3Umw5c8svQ18tz/5bAjFXrJzbx6iZiYlEL3GO7CE l+ZMlBwotXbf+4fI2pa8qYkMJgkUa8qmOp+CCK2+HWA/QHPdS/MLbsP6oD7r6CyE1wZR vOZemAoqS/DQQGm89/AXio44M+bAl+rW9kEFanSgyQKJKqBuXWp95npb1qtgF1PkysJI 8ELrWolMxCDI9rPbqqOGNSJy3+tdVsGt2w0Y3Hdo/IAA8HQw6YRE5PCcY5DpuYG3w+Nv 0UCnLYSk074NNeeNZH2KOmTGuF3mMZ2BJQGLo39fYI1/51FGeQ4eGfZfnzb3N9NSmeLa ziCg== Return-Path: Received: from ?IPv6:2a00:1370:8116:64e8:39b0:446b:af98:5f5? ([2a00:1370:8116:64e8:39b0:446b:af98:5f5]) by smtp.gmail.com with ESMTPSA id q26sm1299484lfb.26.2019.12.11.06.40.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2019 06:40:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: Proposal for the transition timetable for the move to GIT From: Maxim Kuvyrkov In-Reply-To: Date: Wed, 11 Dec 2019 14:40:00 -0000 Cc: "Eric S. Raymond" , Richard Guenther , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C7E86D4-AFDE-4EFB-B804-A03C99042B3E@linaro.org> 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> To: "Joseph S. Myers" X-SW-Source: 2019-12/txt/msg00167.txt.bz2 > On Dec 9, 2019, at 9:19 PM, Joseph Myers wrote: >=20 > On Fri, 6 Dec 2019, Eric S. Raymond wrote: >=20 >> Reposurgeon has been used for several major conversions, including groff= =20 >> and Emacs. I don't mean to be nasty to Maxim, but I have not yet seen=20 >> *anybody* who thought they could get the job done with ad-hoc scripts=20 >> turn out to be correct. Unfortunately, the costs of failure are often=20 >> well-hidden problems in the converted history that people trip over=20 >> months and years later. >=20 > I think the ad hoc script is the risk factor here as much as the fact tha= t=20 > the ad hoc script makes limited use of git-svn. >=20 > For any conversion we're clearly going to need to run various validation= =20 > (comparing properties of the converted repository, such as contents at=20 > branch tips, with expected values of those properties based on the SVN=20 > repository) and fix issues shown up by that validation. reposurgeon has= =20 > its own tools for such validation; I also intend to write some validation= =20 > scripts myself. And clearly we need to fix issues shown up by such=20 > validation - that's what various recent reposurgeon issues Richard and I= =20 > have reported are about, fixing the most obvious issues that show up,=20 > which in turn will enable running more detailed validation. >=20 > The main risks are about issues that are less obvious in validation and s= o=20 > don't get fixed in that process. There, if you're using an ad hoc script= ,=20 > the risks are essentially unknown. But using a known conversion tool wit= h=20 > an extensive testsuite, such as reposurgeon, gives confidence based on=20 > reposurgeon passing its own testsuite (once the SVN dump reader rewrite=20 > does so) that a wide range of potential conversion bugs, that might appea= r=20 > without showing up in the kinds of validation people try, are less likely= =20 > because of all the regression tests for conversion issues seen in past=20 > conversions. When using an ad hoc script specific to one conversion you= =20 > lose that confidence that comes from a conversion tool having been used i= n=20 > previous conversions and having tests to ensure bugs found in those=20 > conversions don't come back. >=20 > I think we should fix whatever the remaining relevant bugs are in=20 > reposurgeon and do the conversion with reposurgeon being used to read and= =20 > convert the SVN history and do any desired surgical operations on it. >=20 > Ad hoc scripts identifying specific proposed local changes to the=20 > repository content, such as the proposed commit message improvements from= =20 > Richard or my branch parent fixes, to be performed with reposurgeon, seem= =20 > a lot safer than ad hoc code doing the conversion itself. And for=20 > validation, the more validation scripts people come up with the better.= =20=20 > If anyone has or wishes to write custom scripts to analyze the SVN=20 > repository branch structure and turn that into verifiable assertions abou= t=20 > what a git conversion should look like, rather than into directly=20 > generating a git repository or doing surgery on history, that helps us=20 > check a reposurgeon-converted repository in areas that might be=20 > problematic - and in that case it's OK for the custom script to have=20 > unknown bugs because issues it shows up are just pointing out places wher= e=20 > the converted repository needs checking more carefully to decide whether= =20 > there is a conversion bug or not. Firstly, I am not going to defend my svn-git-* scripts or the git-svn tool = they are using. They are likely to have bugs and problems. I am, though, = going to defend the conversion that these tools produced. No matter the co= nversion tool, all that matters is the final result. I have asked many tim= es to scrutinize the git repository that I have uploaded several months ago= and to point out any artifacts or mistakes. Surely, it can't be hard for = one to find a mistake or two in my converted repository by comparing it aga= inst any other /better/ repository that one has. [FWIW, I am going to privately compare reposurgeon-generated repo that Rich= ard E. uploaded against my repo. The results of such comparison can appear= biased, so I'm not planning to publish them.] Secondly, the GCC community has overwhelmingly supported move to git, and i= n private conversations many developers have expressed the same view: 1. all we care about is history of trunk and recent release branches 2. current gcc-mirror is really all we need 3. having vendor branches and author info would be nice, but not so nice as= to delay the switch any longer Granted, the above is not the /official/ consensus of GCC community, and I = don't want to represent it as such. However, it is equally not the consens= us of GCC community to delay the switch to git until we have a confirmed pe= rfect repo. -- Maxim Kuvyrkov https://www.linaro.org