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...

[John Baldwin]

On 6/29/20 2:11 PM, Stefan Eßer wrote:
> Am 29.06.20 um 20:09 schrieb Ed Maste:
>> On Mon, 29 Jun 2020 at 11:27, John Baldwin <jhb at freebsd.org> 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).
> 
> I have suggested to the author to add SPDX BSD-2-Clause tags, which
> would change a large fraction of the currently committed files.
> 
> 
> Is it required to perform the --record-only merge, then?
> 
> 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 ...

You can do a --record-only merge now, and then use 'svn merge' to merge
in the new version via the normal workflow.

-- 
John Baldwin