From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109017 invoked by alias); 25 Dec 2019 08:12: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 109004 invoked by uid 89); 25 Dec 2019 08:12:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Proposal, Having, mechanically, SVN X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Dec 2019 08:12:09 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ik1m2-0005B9-QL for gcc@gcc.gnu.org; Wed, 25 Dec 2019 03:12:08 -0500 Received: from linux-libre.fsfla.org ([209.51.188.54]:48382 helo=free.home) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ik1li-000541-P4; Wed, 25 Dec 2019 03:11:47 -0500 Received: from livre.home (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id xBP8BV2X463598 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Dec 2019 05:11:32 -0300 From: Alexandre Oliva To: Jeff Law Cc: Segher Boessenkool , Joseph Myers , "Eric S. Raymond" , Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw \(lists\)" , gcc@gcc.gnu.org Subject: Re: Proposal for the transition timetable for the move to GIT References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <20191216153649.GE3152@gate.crashing.org> Date: Wed, 25 Dec 2019 08:12:00 -0000 In-Reply-To: (Jeff Law's message of "Mon, 16 Dec 2019 10:39:54 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.51.188.54 X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00399.txt.bz2 On Dec 16, 2019, Jeff Law wrote: > Yet Joseph just indicated today Maxim's conversion is missing some > branches. While I don't consider any of the missed branches important, > others might. More importantly, it raises the issue of what other > branches might be missing and what validation work has been done on > that conversion. It also raises another issue, namely the ability to *incrementally* fix such problems should we find them after the switch-over. I've got enough experience with git-svn to tell that, if it missed a branch for whatever reason, it is reasonably easy to create a configuration that will enable it to properly identify the point of creation of the branch, and bring in subsequent changes to the branch, in such a way that the newly-converted branch can be easily pushed onto live git so that it becomes indistinguishable from other branches that had been converted before. I know very little about reposurgeon, but I'm concerned that, should we make the conversion with it, and later identify e.g. missed branches, we might be unable to make such an incremental recovery. Can anyone alleviate my concerns and let me know we could indeed make such an incremental recovery of a branch missed in the initial conversion, in such a way that its commit history would be shared with that of the already-converted branch it branched from? Anyway, hopefully we won't have to go through that. Having not just one but *two* fully independent conversions of the SVN repo to GIT, using different tools, makes it a lot less likely that whatever result we choose contains a significant error, as both can presumably help catch conversion errors in each other, and the odds that both independent implementations make the same error are pretty thin, I'd think. Now, would it be too much of a burden to insist that the commit graphs out of both conversions be isomorphic, and maybe mappings between the commit ids (if they can't be made identical to begin with, that is) be generated and shared, so that the results of both conversions can be efficiently and mechanically compared (disregarding expected differences) not only in terms of branch and tag names and commit graphs, but also tree contents, commit messages and any other metadata? Has anything like this been done yet? -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer FSMatrix: It was he who freed the first of us FSF & FSFLA board member The Savior shall return (true);