About mergemaster (Re: upgrading)

[Peter Jeremy]

On 2003-Sep-22 18:14:21 -0600, Mike Porter <mupi at 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