About mergemaster (Re: upgrading)

[Mike Porter]

-----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-----