From owner-freebsd-questions Wed Dec 13 10: 9:27 2000 From owner-freebsd-questions@FreeBSD.ORG Wed Dec 13 10:09:24 2000 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 017AD37B400 for ; Wed, 13 Dec 2000 10:09:24 -0800 (PST) Received: from FreeBSD.org (Studded@master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA75655; Wed, 13 Dec 2000 10:09:10 -0800 (PST) (envelope-from DougB@FreeBSD.org) Sender: doug@dt051n37.san.rr.com Message-ID: <3A37BB46.316CC5E1@FreeBSD.org> Date: Wed, 13 Dec 2000 10:09:10 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Meyer Cc: "cam (Camille HUOT)" , questions@FreeBSD.org Subject: Re: mergemaster References: <14902.12708.622031.399130@guru.mired.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Meyer wrote: > > cam (Camille HUOT) types: > > On Mon, 11 Dec 2000 22:07:32 +0300 > > "Artem Koutchine" wrote: > > > I wonder if this procedure can be a little bit more automatic. For example, > > > the mergmaster checks if the file have been actually changed, and it was not > > > (from the original file of the prev mergmaster) than it can pretty much > > > install a new > > > version of it, otherwiese - ask the user. The problem is to determine > > > whether it was > > > changed :) What I'm actually working on is a system to use CVS itself to see if the files are different. > > We could modify the CVS tag for example, or add a string > > ### MODIFIED ### > > at the script's beginning > > Yes - but if you don't document that, people will be *very* upset when > it blows away their modified files without telling them (whether or > not it's an option). Using the r/o vs. r/w, at least they had to go > a little out of their way to do it. > > If you're really serious about this, create a directory > /var/mergemaster. Then, when mergemaster installs /$CONFIG_FILE, have > it check for /var/mergemaster/$CONFIG_FILE. If that exists, compare it > to the md5 sum of /$CONFIG_FILE. If the two match, the file hasn't > changed, and you can install the new one - and update the md5 sum in > /var/mergemaster/$CONFIG_FILE. If /var/mergemaster/$CONFIG_FILE > doesn't exist or doesn't match the md5 sum of the file being > installed, ask the user about it as per normal. If you install the new > one, update /var/mergemaster/$CONFIG_FILE, otherwise delete it. You > might want to add an option to let people install the file without > installing /var/mergemaster/$CONFIG_FILE as well. With all due respect to the various contributors to this thread, none of these ideas really fit in with my design model. Specifically, they are all WAY too complicated, and/or violate the principle that mm shouldn't have to know about any specific files. It's designed to only work with what's installed, vs. the files created by /usr/src/etc/Makefile. That way it has a much better chance to work across multiple versions of freebsd, and more importantly, BETWEEN major versions of freebsd. The good news is that with the new enter and exit hooks mergemaster provides you can write your own scripts that handle the types of things that you describe above. Good luck, Doug -- So what I want to know is, where does the RED brick road go? Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message