From owner-freebsd-current@freebsd.org Fri Aug 14 18:25:57 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C54D29B92B7 for ; Fri, 14 Aug 2015 18:25:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 A0F3A1751; Fri, 14 Aug 2015 18:25:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 250F2B93A; Fri, 14 Aug 2015 14:25:56 -0400 (EDT) From: John Baldwin To: Julian Elischer Cc: Slawa Olhovchenkov , freebsd-current@freebsd.org, Baptiste Daroussin Subject: Re: [CFT] rewrite of the merge(1) utility Date: Fri, 14 Aug 2015 10:54:15 -0700 Message-ID: <1946523.qs8tQ2TzQt@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <55CE06F3.9030809@freebsd.org> References: <20150726012619.GP21594@ivaldir.etoilebsd.net> <7204455.dGN1cQ55dZ@ralph.baldwin.cx> <55CE06F3.9030809@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 14 Aug 2015 14:25:56 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 18:25:58 -0000 On Friday, August 14, 2015 11:19:15 PM Julian Elischer wrote: > On 8/13/15 11:23 PM, John Baldwin wrote: > > On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote: > >> On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote: > >> > >>> On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > >>>> Hi all, > >>>> > >>>> I was botherd to not have the merge(1) utility available in base (for etcupdate) > >>>> when building base WITHOUT_RCS. > >>>> > >>>> So I have rewritten a merge(1) utility which should be compatible. > >>>> > >>>> I used the 3-way merge code from the fossil VCS instead of making it call diff3. > >>>> All I have done from the fossil code is adapting it to use sbuf(9). > >>>> > >>>> The bonus for end users is the merge from fossil can resolve situation where the > >>>> diff3 in base cannot. (which explains a "failure" with the GNU RCS test suite) > >>>> > >>>> meaning etcupdate will be more happy merge configuration files. > >>> Thanks! This will save me from having to hack etcupdate to use diff3 instead > >>> of merge. > >> Hi, can I use etcupdate to update /etc w/o source tree? > >> I.e. I take from new distro /var/db/etcupdate and try to update /etc? > > etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock /etc > > into /etc. The "old" stock /etc is always stored in /var/db/etcupdate. > > The "new" stock /etc has to come from somewhere. One option is to generate > > it from /usr/src (e.g. after a buildworld). However, you can also pregenerate > > tarballs from a /usr/src tree on one machine and then use those tarballs > > instead of generating an /etc tree from /usr/src on another machine. I've > > used this for upgrades of a cluster of machines where a single machine would > > build release "images" that were basically a buildworld + an 'etcupdate build' > > from the corresponding src tree. I then used 'etcupdate -t /path/to/tarball' > > to update /etc after installing the new world. > > > > The idea is that for something like freebsd-update one could ship the latest > > etcupdate build tarball on each update to do a full 3-way merge of /etc. > > > what is the rational for using etcupdate instead of mergemaster when > upgrading? It is able to do a full 3-way merge akin to 'svn up' since it has both the old and new versions of the stock files to generate a diff to apply to the version in /etc. mergemaster only has the new version so it cannot do this. etcupdate makes use of this to automatically apply diffs to files when the diffs do not generate a conflict. Only if an update generates a conflict are you required to manually intervene and resolve those conflicts. This makes it more suited to doing automated upgrades of clusters of machines where you don't want to have to always have a person look at each diff of a file changed in /etc. -- John Baldwin