From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 17:58:54 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B3E516A4B3 for ; Mon, 22 Sep 2003 17:58:54 -0700 (PDT) Received: from alcanet.com.au (mail2.alcanet.com.au [203.62.196.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBAE14400B for ; Mon, 22 Sep 2003 17:58:46 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp02.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1])h8N0weeq018742; Tue, 23 Sep 2003 10:58:40 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp02.alcatel.com.au (Lotus Domino Release 5.0.12) with ESMTP id 2003092310583958:2885 ; Tue, 23 Sep 2003 10:58:39 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.9/8.12.9) with ESMTP id h8N0wd7d020797; Tue, 23 Sep 2003 10:58:39 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.9/8.12.9/Submit) id h8N0wbq7020796; Tue, 23 Sep 2003 10:58:37 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Tue, 23 Sep 2003 10:58:37 +1000 From: Peter Jeremy To: Mike Porter Message-ID: <20030923005837.GP91404@gsmx07.alcatel.com.au> Mail-Followup-To: Mike Porter , stable@freebsd.org References: <12829.1064235540@thrush.ravenbrook.com> <3F6F0A0C.1060308@rsm.ru> <447k404pr5.fsf@be-well.ilk.org> <200309221814.26301.mupi@mknet.org> Mime-Version: 1.0 In-Reply-To: <200309221814.26301.mupi@mknet.org> User-Agent: Mutt/1.4.1i X-MIMETrack: Itemize by SMTP Server on SYDSMTP02/AlcatelAustralia(Release 5.0.12 |February 13, 2003) at 23/09/2003 10:58:39 AM,|February 13, 2003) at 23/09/2003 10:58:41 AM, Serialize complete at 23/09/2003 10:58:41 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline cc: stable@freebsd.org Subject: Re: About mergemaster (Re: upgrading) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2003 00:58:54 -0000 On 2003-Sep-22 18:14:21 -0600, Mike Porter wrote: >The only problem with this theory is a significant number of the files flagged >by mergemaster, the only difference is the cvs version tag (in theory, this >shouldn't be happening, since the cvs tag shouldn't update unless something >in the file changes, but I have seen this nonetheless. I can think of three reasons for this: 1) A change is made but is later reverted for various reasons (generally either because the commiter broke a freeze or the commit broke something in an unexpected and difficult-to-fix way). 2) A forced commit was made to better explain a previous commit. 3) The file has been branched (eg you've changed from tracking RELENG_4 to RELENG_4_8) but not modified along the branch. This probably wouldn't be too difficult for mergemaster to detect and ignore. It's also rare enough that it's not clear that implementing the code in mergemaster is worth the effort. > Somewhat along the >same lines are files where the only changes are changes to typos in comments, >or adding/deleting comments, which have no functional difference on the file >itself.). This is a much more difficult area. How do you get mergemaster to automatically differentiate between a comment change that corrects a typo and a comment change that is documenting a change in functionality? Obvious examples of the latter are ssh_config and sshd_config where the default configuration is specified in comments. If you are relying on a particular default, you need to know if it changes. >I would strongly support a mechanism for asking for user input: "file >rc.network is unchaged from default, but the new version is different. >(v)iew/(c)ontinue? [v]" The difficulty here is determing the 'unchanged from default' case. MD5 checksums in an mtree database could give you a yes/no answer but isn't extensible - once you start talking about comparing your current file to the default, the next obvious request is the ability to do a 3-way merge. IMHO, just detecting that a file has or hasn't changed from the then default is of very little benefit without the ability to do a 3-way merge of differences. Peter