Date: Fri, 14 Aug 2015 10:52:04 -0700 From: John Baldwin <jhb@freebsd.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: freebsd-current@freebsd.org, Baptiste Daroussin <bapt@freebsd.org> Subject: Re: [CFT] rewrite of the merge(1) utility Message-ID: <2075305.SMzFbTQNGK@ralph.baldwin.cx> In-Reply-To: <20150814073951.GB1872@zxy.spb.ru> References: <20150726012619.GP21594@ivaldir.etoilebsd.net> <20150813211428.GA1872@zxy.spb.ru> <20150814073951.GB1872@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 14, 2015 10:39:51 AM Slawa Olhovchenkov wrote: > On Fri, Aug 14, 2015 at 12:14:28AM +0300, Slawa Olhovchenkov wrote: > > > On Thu, Aug 13, 2015 at 08:23:02AM -0700, 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 about /var/db/etcupdate from install media? > > Can I use this? > > What best way for work with /var/db/etcupdate from install media > > (storing, saving and etc)? > > As I see, /var/db/etcupdate/current match installed version. > Is this enough? > How I use this? There are a few ways. Newer installs do bootstrap it for you, so if you follow the traditional source upgrade method you can just run 'etcupdate' in place of 'mergemaster'. If you do not want to have a /usr/src tree, how are you updating your world? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2075305.SMzFbTQNGK>