Date: Tue, 23 Sep 2003 01:08:56 -0600 From: Mike Porter <mupi@mknet.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: stable@freebsd.org Subject: Re: About mergemaster (Re: upgrading) Message-ID: <200309230109.06120.mupi@mknet.org> In-Reply-To: <20030923005837.GP91404@gsmx07.alcatel.com.au> References: <12829.1064235540@thrush.ravenbrook.com> <200309221814.26301.mupi@mknet.org> <20030923005837.GP91404@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 22 September 2003 06:58 pm, Peter Jeremy wrote: > 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. > Agreed; I was reacting to the statement about "knowing your configuration," and pointing out that using mergemaster at all means you may not know your computer's configuration. > > 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. > This is very true. In my original message, I started to write something along those lines, but wound up deleting it becuase it made my thoughts nearly unreadable. The only way to reliably do this would be to give mergemaster the intelligence to know about each config file, the various options, etc. at that point, you might as well write a system configuration utility from scratch....even then you would be hard pressed to keep up with changes to defaults and configigurations options, especially since you would be required to do this for the entire system (or at least anything that keeps files in /etc; this absolves you of most of the ports, but the base system alone would drive you nuts) > >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. > My vision of the [v]iew option would be that it would take you in to the 'normal' functioning of mergemaster. In other words, if the file is unchanged from the original run (using whatever mechanism we wish to determine this), then instead of presenting the user with the diff output that might just consist of a few comment lines changes, or a typo correction, we give the user the option of (blindly) accepting the new version, or looking to see what's changed (notice I didn't suggest an "all" option here!). Since we are in the context of mergemaster to start with, "looking to see what's changed" implies (at least in my twisted mind) the 3-qway merge options. Also, it would bre trivial to add a setting to /etc/mergemaster.rc to control whether or not to use this feature. I'll have to play with it some on my system and see if I can make it work right... Mergemaster should also be made sufficiently intelligent to automatically bring up the 'merge' screen for files we KNOW are going to be different than the temporary environment, such as /etc/groups, /etc/passwd or /etc/master.passwd, /etc/printcap and /etc/aliases. In essence, for these files, you'd want to just add any lines that appear in only the 'current' version, to the 'new' version, provided no conflicts exist (ie, they don't try to define different groups/users to the same gid/uid. In the case of printcap, you'd want to make sure that two entries didn't both try to define the 'lp' device. Come to think of it, since printcap is documented in printcap(5), rather than /etc/printcap, that file could probably be permanently removed from the list of files processed, couldn't it? Well, it's past my bedtime here and the muscle relaxer is kicking in, I better sign off before I get *really* incoherent.... mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/b/GRY30jZzkECLcRAkAfAJ4o6OfRs4KD+z2460zW2U/TJh74ogCeJT5q ceJtrzjHSC0Q5PI1N2m0dxc= =de81 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309230109.06120.mupi>