question on mergemaster

Garance A Drosihn drosih at rpi.edu
Mon Jan 19 11:29:00 PST 2004


At 1:16 PM -0600 1/19/04, Eric Anderson wrote:
>Garance A Drosihn wrote:
>
>>This is probably easier to implement, but there is still a
>>good chance that someone will make an important change to
>>some /etc file, and:
>>    1) not-know to add the line
>>       (documentation?  Who reads documentation?)
>>    2) know, but still forget to do it
>>    3) remember to do it, but misspell the magic line.
>>
>>And at some future system update their change will be automatically
>>and quietly erased.  And depending on the change, they might not
>>realize that it is gone until weeks or months after having made
>>the mistake.
>>
>>I think it would be a mistake if we streamline mergemaster to
>>the point that users can easily start losing updates.
>
>
>I think you missed something - "some sort of switch to mergemaster
>to tell it to go into autoupdate mode" - which I understood it to
>mean, that the default action will not change, unless you use a
>"mergemaster -I" or some such beast..

That helps some, but it doesn't help if at some later date
they forget to add the magic line to some file they changed.
It doesn't help if they make a typo on the line -- so that
they *think* their change will be saved but in fact it won't be.

My assumption is that people would immediately gravitate to
using this new method, just because they want to get rid of
all the questions.  Once they do that (by putting it into
.mergemasterrc), files will then change on them without any
warning or reminder to them.

In my own case, I'm not sure I'd trust myself enough to use the
proposed option, in which case the option doesn't do me any good.
It's an all-or-nothing change (ie, it will determine how *all*
files are handled), and I am just more comfortable using an option
which is more limited in scope.  That's just my opinion on it,
of course.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu


More information about the freebsd-current mailing list