From owner-freebsd-stable@FreeBSD.ORG Fri Mar 13 07:55:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B66AD1065672 for ; Fri, 13 Mar 2009 07:55:30 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 90BEC8FC1A for ; Fri, 13 Mar 2009 07:55:30 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n2D7aeDp055100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2009 00:36:40 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n2D7ae0B055099; Fri, 13 Mar 2009 00:36:40 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA04218; Thu, 12 Mar 09 23:26:58 PST Date: Fri, 13 Mar 2009 00:26:17 -0700 From: perryh@pluto.rain.com To: doconnor@gsoft.com.au Message-Id: <49ba0a99.zRpbA1XAX3ZA0YOG%perryh@pluto.rain.com> References: <200903121505.n2CF5RXx047734@lurza.secnetix.de> <200903131054.40000.doconnor@gsoft.com.au> In-Reply-To: <200903131054.40000.doconnor@gsoft.com.au> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: mergemaster annoyance or not? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 07:55:31 -0000 "Daniel O'Connor" wrote: > I wonder how hard it would be to add 3 way merging (like > sysutils/etcmerge) to mergemaster.. One complication: to do a 3-way merge you have to have the common ancestor. To ensure the initial availability of such would require some infrastructure which AFAIK does not currently exist: * A standardized place to keep the original contents of /etc -- /origEtc or /etc- anyone? * A way to ensure that installation populates that place with the needed redundant copy of the bits, either by including the additional instance within the distributions or by generating it in the course of installation. The former would likely be easier, if only because the latter would need to work for all installation methods.