Re: make upgrade overwrites /etc/mail/mailer.conf

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: (Simon)
:Ah well, a little bit long. But most changes can actually be applied=20
:without collisions. Which means the user just gets presented (if he opted=20
:in/not out) his changed version and the new merged version. most time=20
:they will just say "yes, okay, that looks good. where was the change=20
:anyways"
:
:> (Chris Pressey)
:> What do people think about using CVS for this?

    Chris, that's a great idea.

:I'd rather use RCS, the remote and can-checkout multiple times features=20
:are not needed here.
:
:> - Standard tool with general applicability, in the base system.
:> - Designed for handling merges and any conflicts that arise.
:> - The admin can specify which files not to touch, using .cvsignore.
:> - The admin can make unobtrusive comments on their changes, in the log.
:> - The admin can roll back their configuration to any previous point.
:
:all that is possible with RCS, too

    I don't think RCS tracks the checked out files, though, at least not
    by default, and if we are going to automate detection we need that.

    If we use CVS here then the make upgrade code can trivially look
    for a CVS/Entries file.  So e.g. it would be able to automatically
    determine that a file it normally installs is under CVS by greping
    it in CVS/Entries and it can do a three-way merge instead of 
    overwriting the file.

    I think I would prefer one supported solution and that is sounding
    like CVS to me.   You can't beat having a convenient CVS/Entries file
    to play with.

    I should have thought of this, we used CVS at BEST Internet for certain
    selected admin files.  In fact, I had a CVS hierarchy rooted at '/'.  CVS
    is smart enough to only recurse through the directories that have been
    specifically cvs added so this was used to update more then just /etc.

    But, more to the point, the burden of setting up CVS is not something
    the release build has to worry about.  If the sysad sets it up, the
    release build will deal with it.  If the sysad doesn't set it up, the
    release build will simply overwrite files.  Best of both worlds.
	
					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:cheers
:  simon