From owner-svn-src-all@freebsd.org Mon Jun 29 22:21:16 2020 Return-Path: Delivered-To: svn-src-all@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 AE053356FCE; Mon, 29 Jun 2020 22:21:16 +0000 (UTC) (envelope-from pfg@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 49whlw40CJz4Wlr; Mon, 29 Jun 2020 22:21:16 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id B68B81A96B; Mon, 29 Jun 2020 22:21:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r362681 - in head: contrib/bc contrib/bc/gen contrib/bc/include contrib/bc/locales contrib/bc/manuals contrib/bc/src contrib/bc/src/bc contrib/bc/src/dc contrib/bc/src/history contrib/b... To: =?UTF-8?Q?Stefan_E=c3=9fer?= , Ed Maste , John Baldwin Cc: Eric van Gyzen , src-committers , svn-src-all , svn-src-head References: <202006271202.05RC22oR085945@repo.freebsd.org> <2b7f0d0f-e243-9c9c-f1c0-e700e0bf6d48@FreeBSD.org> <577b1bd1-598a-d3f9-3c23-537b9747612a@vangyzen.net> <8670f956-1ed4-2b87-ee64-d04bc37d6810@freebsd.org> From: Pedro Giffuni Organization: FreeBSD Message-ID: <0307b190-136c-59d1-bbde-976e6b181868@FreeBSD.org> Date: Mon, 29 Jun 2020 17:21:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 22:21:16 -0000 On 29/06/2020 16:11, Stefan Eßer wrote: > Am 29.06.20 um 20:09 schrieb Ed Maste: >> On Mon, 29 Jun 2020 at 11:27, John Baldwin wrote: >>> I suspect just doing the 'merge --record-only' is the simplest method >>> assuming Git handles it ok. I suspect since Git ignores mergeinfo this >>> is fine, but it would be good for Ed to confirm. You can always restore >>> the tests in the future in contrib/bc when you want to add them. >> I think a --record-only merge is the best approach; in any case we >> have a number of these in the tree already and Git will have to deal >> with them. > Thank you for this advice. > > There is a new version, which differs only in the man-pages. These > used to mention optional features (of which only NLS support is > actually optional in the version built on FreeBSD, all other are > always compiled in, and I had mentioned to the author that this > might irritate FreeBSD users). FWIW, since it was rewritten it would have been actually nice to have it in modern C++. > I have suggested to the author to add SPDX BSD-2-Clause tags, which > would change a large fraction of the currently committed files. We only use the SPDX tags for internal software. For stuff from contrib it is not necessary. > > Is it required to perform the --record-only merge, then? Since you are going to bring it through the vendor area you should keep the merge information yes. > Or would it be OK to import the new release into the vendor branch > and then svn copy that version completely (including the tests and > other files that I had omitted in the initial import) to contrib? > > I expect the svn copy without prior svn merge --record-only to > result in the same repository state after the conversion to Git, > but I do not really know ... It is likely git won't care. cheers, Pedro.