From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 9 23:55:47 2003 Return-Path: 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 E6D0437B401 for ; Wed, 9 Apr 2003 23:55:46 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B2D843F85 for ; Wed, 9 Apr 2003 23:55:46 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <2003041006554400300fcem4e>; Thu, 10 Apr 2003 06:55:45 +0000 Date: Wed, 9 Apr 2003 23:55:43 -0700 (PDT) From: Doug Barton To: "Brandon D. Valentine" In-Reply-To: <20030321041548.GY25577@geekpunk.net> Message-ID: <20030409232506.T1708@znfgre.tberna.bet> References: <20030321041548.GY25577@geekpunk.net> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-Hackers Subject: Re: generalized mergemaster(8) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2003 06:55:47 -0000 Sorry I didn't respond to this thread sooner, I was busy with ICANN stuff the last few weeks. I've read the various proposals, and I'll respond to a few individually. I would like to make a few general comments though. When I sat down to create mergemaster, I had two main goals. The first was to make it safe, so that users, especially novice users wouldn't have to worry when running it. The primary way I tried to do that is to make sure that it never does anything by default, only by user-chosen action. The other goal was to make it as "dumb" as possible, that is it knows as little as possible about specific files, instead it operates on what it finds in TEMPROOT. This allows it to be a lot more flexible, and usable without changes, even after things change around it. A third goal evolved over time, as people started using the same code on other platforms. A lot of people have suggested a lot of ways to expand mergemaster over the 5 years I've been working on it. I tend to resist a lot of them because they violate the design goals I started with (and thereby dramatically increase the risk to users); and because the current incarnation of the script is too complex, and has too many options already. Of course, there are things that I would _like_ to add, but doing these things has proven to be a lot more complicated than I'd like, and time is limited. I did add the pre and post compare script hooks to help add flexibility for people that have requested things that were really out of scope, but I haven't been able to come up with the /usr/share/examples/mergemaster stuff that I was hoping to. Of course, the folks who've promised to send me their own examples haven't done that either. :-/ If it's time for "son of mergemaster" to be developed by someone else, I have no problem with that. I do have a problem with taking mergemaster and turning it into something it was never intended to be. On Thu, 20 Mar 2003, Brandon D. Valentine wrote: > I have encountered a situation in which it would be extremely handy to > have a generalized version of mergemaster(8) which is less specific to > the task of merging /etc. I need to recursively merge two directories > of source files in which I wish to preserve some original files, install > some replacement files outright, and only actually go to the trouble of > sdiff(1)ing those files that from the preview udiff look like they are > need of a merge. Has anyone already done the work of generalizing > mergemaster to this more general task? And if not, is there interest in > this? If nobody has done it I'm probably about to. My inclination is > to extend the existing mergemaster script to support this general > functionality while maintaining support for the specific case of an /etc > merge. mergemaster(8) is already fairly applicable to this task but it > currently makes some assumptions about what your $Id$ looks like and > that you will in fact be running make(1) somewhere to generate your > temproot. I don't think that including this as part of mergemaster is really a good idea, since as you point out, mergemaster makes a lot of assumptions that are specific to its purpose. I would obviously have no objections to you cribbing the code for a similar utility though. One approach that I'd support would be to pull the "compare the contents of two directories" code out into another script, and let mergemaster call that script. However I don't have time to write such a thing. HTH, Doug -- This .signature sanitized for your protection