svn: head/usr.sbin/mergemaster

[Roman Kurakin]

Ivan Voras wrote:
> 2009/1/3 Julian Elischer <julian at elischer.org>:
>   
>> Ivan Voras wrote:
>>
>>     
>>> And just how can upgrading all the non-user-modified files cause
>>> serious damage here (serious=system not bootable, login not possible,
>>> etc)? Please explain with examples, since from this and the old
>>> current@ thread I only got the impression that "it's baaaad, m'kay".
>>> Note that regular users will not upgrade -CURRENT, and most won't even
>>> upgrade -STABLE, but will go from one -RELEASE to another. Speaking
>>> for myself, mergemaster is a source of constant irritation because it
>>> doesn't do auto-upgrades by default, and I'm often tempted to just not
>>> start it rather than going through 15 minutes of "q, i, <enter>" (my
>>> pages is less, thus the "q").
>>>       
>> Not to mention the times when it seems some large number of files
>> get a change in CVS ID or whatever for some reason (and no other change (for
>> example someone put a tem change in some subset of
>> the rc.d files and then removed it) which seems to happen
>> regularly, then you have to go i i i i i i i i i i i i i i i
>> for 10 minutes, and then you get into finger-typeahead and
>> it then goes right past the one file you DIDN'T want to change
>> and you have lost /etc/master.passwd or something.
>>     
>
> Yes, I completely forgot to rant about the typeahead problem :)
>
> On the other hand, this might point to a user-interface problem. Maybe
> if instead of constantly requesting user input it could be modified to
> work differently - maybe it could generate a machine readable report
> of files and autoload it in $EDITOR, in which the user could mark the
> files en masse (in some easy way, for example by killing the lines
> containing filenames he doesn't want to upgrade, prepending filenames
> with "m" for merging, etc), which would then be processed by the
> script? But again this would save irritation only if there's a quick
> way to specify "just upgrade everything that wasn't changed by the
> user".
>   
The better way would be to specify path_to_cvs and do three way merging.
>> The -U option goes part way towards this.. How does it know what files
>> have not been user modified?  Does it store hashes from the last run
>> somewhere?
>>     
>
> I think that's what /var/db/mergemaster.mtree is used for.
>