From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 30 15:01:15 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C8A816A41F; Fri, 30 Sep 2005 15:01:15 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B8343D49; Fri, 30 Sep 2005 15:01:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8UF16RI061548; Fri, 30 Sep 2005 19:01:06 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8UF15so061546; Fri, 30 Sep 2005 19:01:05 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Sep 2005 19:01:05 +0400 From: Yar Tikhiy To: John Baldwin Message-ID: <20050930150105.GA55158@comp.chem.msu.su> References: <20050929224548.GB3035@comp.chem.msu.su> <20050930110841.GC45907@comp.chem.msu.su> <200509300907.17730.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509300907.17730.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@FreeBSD.org, Jon Dama Subject: Re: A smarter mergemaster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 15:01:15 -0000 On Fri, Sep 30, 2005 at 09:07:16AM -0400, John Baldwin wrote: > On Friday 30 September 2005 07:08 am, Yar Tikhiy wrote: > > [Replying to everyone who mentioned etcmerge or 3-way merge in general] > > > > On Fri, Sep 30, 2005 at 12:15:59AM -0700, Jon Dama wrote: > > > It is worth while to mention sysutils/etcmerge. > > > > > > Having the "three-way" merge makes the process much better. The primary > > > way I've shot myself with mergemaster is forgetting some local change. > > > > > > Being able to distinguish the class of things that are changing upstream > > > really helps the situation and provides a more reasonable indication of > > > the default: > > > if it changed upstream but not locally => default is install > > > if it changed locally but not upstream => default is keep > > > if it changed locally and upstream => default is merge > > > > Obviously, in order to do a 3-way merge, we need information about > > the old versions of original files as well. However, currently we > > have only the new versions in /usr/src and local versions in /etc > > for mergemaster to work with. I'll be glad to hear how etcmerge > > approaches this issue. > > > > In any case, we cannot offer the users to access the CVS repo when > > merging /etc. Personally, I'd like to see a complete copy of current > > unmodified /etc files installed to /usr/share/examples/etc. They > > could serve as the old original versions for the 3-way merge then. > > Alas, now the copy installed there is rather incomplete, motivation > > of which is unknown to me yet. Any ideas? > > I do the equivalent of etcmerge (sort of) by hand using some old instructions > from the handbook (pre-mm). Basically, for each installworld, you do a > distribute of src/etc into /var/tmp/root-YYMMDD. Then you keep around the > previous tree and just compare the two previous trees and merge those changes > into /etc. I'm curious if we can do this in the stock system using the stock tools. We could compare /usr/share/examples/etc with the results of "make distrubution" and merge the changes into /etc. Mergemaster invokes "make distrubution" anyway, so it just needs relevant /usr/share/examples/etc to be able to do a 3-way merge. This assumes that /usr/share/examples/etc is in keeping with /etc, of course, but the assumption can be verified using RCS Id strings, which should be the same here and there. -- Yar