Date: Tue, 23 Sep 2003 10:58:37 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Mike Porter <mupi@mknet.org> Cc: stable@freebsd.org Subject: Re: About mergemaster (Re: upgrading) Message-ID: <20030923005837.GP91404@gsmx07.alcatel.com.au> In-Reply-To: <200309221814.26301.mupi@mknet.org> References: <12829.1064235540@thrush.ravenbrook.com> <3F6F0A0C.1060308@rsm.ru> <447k404pr5.fsf@be-well.ilk.org> <200309221814.26301.mupi@mknet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2003-Sep-22 18:14:21 -0600, Mike Porter <mupi@mknet.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030923005837.GP91404>