From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13266 invoked by alias); 1 Nov 2019 16:14:46 -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 13258 invoked by uid 89); 1 Nov 2019 16:14:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:svnmerg, reposurgeon, gcc-conversion, mergeinfo X-HELO: esa2.mentor.iphmx.com Received: from esa2.mentor.iphmx.com (HELO esa2.mentor.iphmx.com) (68.232.141.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Nov 2019 16:14:44 +0000 IronPort-SDR: nbQp6SFUuyoZzyQkVkdT+PDC7OMFjbJqCKf1neYdf85XzbewI9lZEXIPZOWPKmnB3In340W1y2 NMaL0nXvM2zNDU/Ts0SFME/YByup+h6hen67bxmdLAXLst+zZCH+MbhYuBTtTeOrqzgRBoB+to 1p/7s4m/RKu8QEDko4ZrlrzPaJkg2Y+jNXohLCOmKF9DYNuO2+D3Rwmh5Lbu9euRyNbHGK35FS k5QuSZOR3ZeVkjF6aOIX8rrcmipWR7q6470RBAkVONDSk7R+NmEtCv7899HqJmnvBX0hVuB5BK 3JU= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 01 Nov 2019 08:14:43 -0800 IronPort-SDR: fxGluAzzDwQXiS8SAivFlQbWThYTbZHIUc6HIpgSh27SSWCwB+xAPFVlcPGxZn37l+JjlzqGxg hEYo2Ei1hKDjsp8U9HpQV8vjWK3cBXSnpttLPp9o0EY3GhEJh5XDmF6d5dxMWgesub8LjZkLCJ gxbjd7qJjAixPEmfgKHDjF498Ncj2dFd+GI8a0FSeZ/scIC5Q+tODD5Hq2YvBtxAf0DAS9oKhL qWaurk5o2gd3sagPYAjXF0opDEAMmSKGNmqvG+nbMw4V0gFyEnfnjudK1eCpcoG7cSmXssWiwn cuk= Date: Fri, 01 Nov 2019 16:14:00 -0000 From: Joseph Myers To: "Eric S. Raymond" CC: Subject: Re: Fixing cvs2svn branchpoints In-Reply-To: <20191101044518.GA95565@thyrsus.com> Message-ID: References: <20191101044518.GA95565@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-11/txt/msg00008.txt.bz2 On Fri, 1 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > Here are complete lists of reparentings I think should be done on the > > commits that start branches, along with my notes on branches with messy > > initial commits but where I don't think any reparenting should be done. > > The REPARENT: lines have the meaning I described in > > . > > Please leave this as an issue on the gcc-conversion bugtracker. Done. . As noted there, I think this ought just to be a single reposurgeon reparent command for each of those 39 REPARENT lines, but I'm wary of adding those 39 reparent commands in a merge request without testing, and don't have any systems with more than 128 GB of memory to hand to test on. (Incidental note: I'm taking the reparent syntax from the reposurgeon sources, that command doesn't seem to be documented in reposurgeon.adoc although it used to be documented in reposurgeon.xml.) A similar issue may well apply to some tags, since tags and branches are essentially the same thing in SVN, and I hope to make such checks for tags as well. > >There are also cases where cvs2svn found a good branchpoint, but > >represented the branch-creation commit in a superfluously complicated > >way, replacing lots of files and subdirectories by copies of different > >revisions. > > Yes, reposurgeon has logic to detect and deal with this automatically. > The assumption it makes is that the branch should root to the most > recent revision that CVS did a copy from. This is simple and seems to > give satisfactory results. Once we have a full conversion we should extract details from it of the branch roots reposurgeon identified, for further checks on them. There are lots of mid-branch commits that also have commit messages of the form "This commit was manufactured by cvs2svn to create branch 'X'". Those mid-branch commits should *not* be turned into merge commits. The typical situation resulting in such a mid-branch commit was that a file (typically a testcase) first created on HEAD then got backported to a branch, so cvs2svn means that commit created the branch *for that particular file" (so it's typically part of a cherry-pick, not a merge, though some CVS-era merges may have created such commits as well). > Which reminds me. I found a bunch of "svnmerge-integrated" properites > in the history. Should I treat those as though they were mergeinfo > properies and make branch merges from them? I think that's what those properties logically are, so making them into merges makes sense if that's easy to do. -- Joseph S. Myers joseph@codesourcery.com