Re: [CFT] rewrite of the merge(1) utility

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