From owner-freebsd-hackers@freebsd.org Fri Jul 10 19:39:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5129371B1E for ; Fri, 10 Jul 2020 19:39:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3NfS47vzz3YMJ; Fri, 10 Jul 2020 19:39:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bb900bc86521febb2afc9.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:b900:bc86:521f:ebb2:afc9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E9FAB1060A; Fri, 10 Jul 2020 19:39:43 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Huge mergeinfo list after merge from vendor branch To: "Rodney W. Grimes" References: <202007101640.06AGeloK096110@gndrsh.dnsmgr.net> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Cc: FreeBSD Hackers Message-ID: <09e7f77b-7d7d-f5ee-5432-c63f4932e979@freebsd.org> Date: Fri, 10 Jul 2020 21:39:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <202007101640.06AGeloK096110@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 19:39:44 -0000 Am 10.07.20 um 18:40 schrieb Rodney W. Grimes: >> We have gathered lots of mergeinfo junk in the source tree over the >> decades, but I did not know it was so bad ... >> >> >> I had not performed any merges for a long time and now that I have >> to merge from the vendor branch to contrib in -CURRENT, I'm surprised >> by the long mergeinfo list I got: >> >> $ svn propget svn:mergeinfo -R /usr/src/contrib/bc >> . - /projects/bectl/contrib/bc:336666-337662 >> /projects/bsd_rdma_4_9/contrib/bc:319973-326168 >> /projects/bsnmp-improved-ipv6-support/contrib/bc:301868 >> /projects/building-blocks/contrib/bc:275142-275143,275198,275297,275306-275307,275309,275311,275556,275558,275600,277445,277670,277673 >> /projects/clang-sparc64/contrib/bc:262258-262612 >> /projects/clang-trunk/contrib/bc:283596-287505 >> [...] >> /vendor/bc/dist:362987-363077 >> /vendor/device-tree/dist/contrib/bc:303380 >> /vendor/resolver/dist/contrib/bc:1540-186085 >> >> A total of 56 lines, which are not relevant to this software, except for >> the 3rd last line: >> >> /vendor/bc/dist:362987-363077 >> >> Before causing a mess in the repo by committing the merged sources, >> I'd like to know whether this is "normal" behavior, or whether I need >> to clean up the mergeinfo before the commit. >> >> Thanks in advance, STefan >> >> PS: The committers handbook has quite some information regarding this >> kind of merge, but it makes me think that only the relevant mergeinfo >> line should have been registered ... Hi Rodney, thank you for responding. I'm holding back a bug-fix commit due to this situation, and I'd like to get the commit done ... > Was a merge done from the wrong working directory? I do not think that this was the case. BTW: Chapter 5.3 of the Developers Handbook gives this advice: % cd head/contrib/foo % svn update % svn merge --accept=postpone ^/vendor/foo/dist I have reverted the merge in my check-out, verified that the mergeinfo was gone and then performed the MFV again with the following command, just to be sure: % cd /usr/svn/base/head % svn merge --accept=postpone ^/vendor/bc/dist contrib/bc The result is exactly the state of before the revert and reapplied MFV, with 56 lines of mergeinfo (pre-dating the vendor import, and applying to other contrib/bc paths, e.g.: /projects/pf/head/contrib/bc:263908. > Merges need to be done while cwd is the top level of the src tree. Yes, I know, and I did it that way (despite the differing advice given in the Developers Handbook). > If done in a subdirectory a massive pile of unwanted mergeinfo is created. And I have repeated the same merge command from within /usr/svn/base (i.e. one level below the head directory), again with identical results. > You can step back through the merge commits and see when this happened. The contents of contrib/bc has been created via "svn copy" from the vendor area, this is the first attempted MFV that updates the contrib directory beyond the initial import. The mergeinfo is for prior revisions of files in **/contrib/bc, e.g. in project or user directories in our SVN repository, which are in no way related to the commit I'm about to do. If I do not receive any direct advice how to resolve this situation, I'll do the commit, anyway. I could force a correct mergeinfo with propset svn:mergeinfo, I assume, but I'm afarid this could lead to breakage or consistency problems later-on. Best regards, STefan