From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81856 invoked by alias); 26 Dec 2019 21:19:19 -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 81830 invoked by uid 89); 26 Dec 2019 21:19:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=changelogs, repodiffer, ChangeLogs, surgery X-HELO: snark.thyrsus.com Received: from thyrsus.com (HELO snark.thyrsus.com) (71.162.243.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Dec 2019 21:19:18 +0000 Received: by snark.thyrsus.com (Postfix, from userid 1000) id 8DC734704B1C; Thu, 26 Dec 2019 16:19:16 -0500 (EST) Date: Thu, 26 Dec 2019 21:19:00 -0000 From: "Eric S. Raymond" To: Alexandre Oliva Cc: Jeff Law , Segher Boessenkool , Joseph Myers , Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191226211916.GA116941@thyrsus.com> Reply-To: esr@thyrsus.com References: <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <20191216153649.GE3152@gate.crashing.org> <20191225120747.GA96669@thyrsus.com> <20191226191607.GA8608@thyrsus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00431.txt.bz2 Alexandre Oliva : > I don't see that it does (help). Incremental conversion of a missed > branch should include the very same parent links that the conversion of > the entire repo would, just linking to the proper commits in the adopted > conversion. git-svn can do that incrementally, after the fact; I'm not > sure whether either conversion tool we're contemplating does, but being > able to undertake such recovery seems like a desirable feature to me. It's all in what you have in the lift script. Reposurgeon can do any kind of branch surgery you want, and that can be added to the conversion pipeline and replicated every time. > >From what I read, he's doing verifications against SVN. What I'm > suggesting, at this final stage, is for us to do verify one git > converted repo against the other. There are no tools for that, and probably won't be unless somebody revives repodiffer. There isn't a lot of time left in the schedule for that, and I have my hands full fixing other glitches. (Minor issues about parsing ChangeLogs and generated .gitignores; the serious problems are well behind us at this point.) > Maxim appears to be doing so and finding (easy-to-fix) problems in the > reposurgeon conversion; it would be nice for reposurgeon folks to > reciprocate and maybe even point out problems in the gcc-pretty > conversion, if they can find any, otherwise the allegations of > unsuitability of the tools would have to be taken on blind faith. Joseph has already made the call to go with a reposurgeon-based conversion for reasons he explained in detail on this list. Given that, it really doesn't make any sense for me to do any of what you're proposing with time I could use working on Joseph's RFEs instead. If you're concerned about the quality of reposurgeon's conversion, you'd be a good person to work on a comparison tool. Should I email you a copy of the repodiffer code as it last existed in my repository? -- Eric S. Raymond