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
=2D----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,"= =20 and pointing out that using mergemaster at all means you may not know your= =20 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 al= ong=20 those lines, but wound up deleting it becuase it made my thoughts nearly=20 unreadable. The only way to reliably do this would be to give mergemaster= =20 the intelligence to know about each config file, the various options, etc. = =20 at that point, you might as well write a system configuration utility from= =20 scratch....even then you would be hard pressed to keep up with changes to=20 defaults and configigurations options, especially since you would be requir= ed=20 to do this for the entire system (or at least anything that keeps files in= =20 /etc; this absolves you of most of the ports, but the base system alone wou= ld=20 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=20 'normal' functioning of mergemaster. In other words, if the file is=20 unchanged from the original run (using whatever mechanism we wish to=20 determine this), then instead of presenting the user with the diff output=20 that might just consist of a few comment lines changes, or a typo correctio= n,=20 we give the user the option of (blindly) accepting the new version, or=20 looking to see what's changed (notice I didn't suggest an "all" option=20 here!). Since we are in the context of mergemaster to start with, "looking= =20 to see what's changed" implies (at least in my twisted mind) the 3-qway mer= ge=20 options. Also, it would bre trivial to add a setting to /etc/mergemaster.r= c=20 to control whether or not to use this feature. I'll have to play with it=20 some on my system and see if I can make it work right... Mergemaster should also be made sufficiently intelligent to automatically=20 bring up the 'merge' screen for files we KNOW are going to be different tha= n=20 the temporary environment, such as /etc/groups, /etc/passwd or=20 /etc/master.passwd, /etc/printcap and /etc/aliases. In essence, for thes= e=20 files, you'd want to just add any lines that appear in only the 'current'=20 version, to the 'new' version, provided no conflicts exist (ie, they don't= =20 try to define different groups/users to the same gid/uid. In the case of=20 printcap, you'd want to make sure that two entries didn't both try to defin= e=20 the 'lp' device. Come to think of it, since printcap is documented in=20 printcap(5), rather than /etc/printcap, that file could probably be=20 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 bet= ter=20 sign off before I get *really* incoherent.... mike =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/b/GRY30jZzkECLcRAkAfAJ4o6OfRs4KD+z2460zW2U/TJh74ogCeJT5q ceJtrzjHSC0Q5PI1N2m0dxc=3D =3Dde81 =2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309230109.06120.mupi>