From owner-freebsd-arch@freebsd.org Mon Jun 18 17:08:38 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95DA910135BD for ; Mon, 18 Jun 2018 17:08:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D7C680B3 for ; Mon, 18 Jun 2018 17:08:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 2301D10AFD4; Mon, 18 Jun 2018 13:08:29 -0400 (EDT) Subject: Re: upstream for contrib/tzcode/stdtme? To: Eitan Adler References: <20a85a8f-29a7-0d8f-64d1-9ba005ffe79c@FreeBSD.org> Cc: "freebsd-arch@freebsd.org" From: John Baldwin Message-ID: <10e35d23-37d8-edf4-fa3b-9663bfdaa629@FreeBSD.org> Date: Mon, 18 Jun 2018 10:08:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 18 Jun 2018 13:08:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:08:38 -0000 On 6/15/18 4:09 PM, Eitan Adler wrote: > On 15 June 2018 at 11:31, John Baldwin wrote: > >> I think this second approach is actually a better plan and is not quite what you >> were suggesting. >> >> That is, import the vendor bits corresponding to our existing code first into >> the vendor area, > > > then svn cp our existing files from libc, zic, etc. into the >> contrib/stdtime tree in the correct layout and do a single 'svn merge --record-only' >> merge to initialize the vendor mergeinfo. >> At that point you should be able to >> svn diff contrib/stdtime against the vendor/stdtime/dist to determine what local >> changes we have and start to think about them. > > At this point both vendor and contrib have the same files, same > layout, but possibly different content? Yes. The different content would be our local changes. > How do we do the update itself then? "svn merge" from the vendor area > into contrib? Yes, just like a normal vendor update. -- John Baldwin