freebsd-update с 8.3-RELEASE до 9.0-RELEASE: как бороться с десятками различий?

Я обновляю систему FreeBSD 8.3-RELEASE до FreeBSD 9.0-RELEASE, используя freebsd-update. Я впервые выполняю обновление основной версии FreeBSD.

В какой-то момент freebsd-update выполняет сравнение файлов, которые отличаются от ожидаемых для 9.0-RELEASE. Он сравнивает текущую версию в системе с новыми изменениями, добавленными из 9.0-RELEASE. Я изменил пару десятков файлов в каталоге / etc, и я получаю эту разницу один раз для каждого файла.

Таким образом, мне представлены десятки и десятки различий, которые открываются в окне vi и выглядят так:

The following file could not be merged automatically: /etc/ntp.conf
Press Enter to edit this file in vi and resolve the conflicts
manually...

### vi window opens

<<<<<<< current version
driftfile /etc/ntp/drift
=======
#
# $FreeBSD: release/9.0.0/etc/ntp.conf 195652 2009-07-13 05:51:33Z dwmalone $
#
# Default NTP servers for the FreeBSD operating system.
#
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
#
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
#
>>>>>>> 9.0-RELEASE

restrict default notrust nomodify ignore

И он жалуется на второстепенные номера версий:

--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.25.28.1 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: src/gnu/usr.bin/man/manpath/manpath.config,v 1.25.32.1 2010/12/21 17:10:29 kensmith Exp $
 #
 # This file is read by manpath(1) to configure the mandatory manpath,
 # optional manpath and to map each path element to a manpath element.
 # The format is:
 #
Does this look reasonable (y/n)? y

И он жалуется на строку версии RCS в десятках файлов:

--- current version
+++ new version
@@ -1,4 +1,4 @@
-# $FreeBSD: src/etc/amd.map,v 1.10.8.1 2009/04/15 03:14:26 kensmith Exp $
+# $FreeBSD: release/9.0.0/etc/amd.map 164015 2006-11-06 01:42:11Z obrien $
 #
 /defaults       type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
 *               opts:=rw,grpid,resvport,vers=3,proto=tcp,nosuid,nodev
Does this look reasonable (y/n)?

И даже жалуется, потому что я удалил номер версии FreeBSD из своего локального (пользовательского) /etc/passwd файл:

<<<<<<< current version
=======
# $FreeBSD: release/8.4.0/etc/master.passwd 243948 2012-12-06 11:54:25Z rwatson $
#
>>>>>>> 8.4-RELEASE
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin

И так далее.

Это требует, чтобы я вручную редактировал каждый файл и удалял строки вроде <<<<<<< current version >>>>>>> 9.0-RELEASE и =======, и вручную объединить эти файлы. Как я впоследствии обнаружил, если я не удаляю эти строки, они впоследствии оказываются в файле. Есть десятки файлов, которые различаются между версиями 8.3 и 9.0, и у меня самого есть десяток локальных модификаций.

Кажется, что freebsd-update использует diff, sdiff или функция mergemaster в каком-то роде, но я не могу точно сказать, что он делает.

Обработка этих файлов утомительна. Есть ли способ сказать «Принять новую версию», «Оставить старую версию» или «Ваше слияние правильное»? Должен быть более простой способ работать с этими файлами. Я, должно быть, что-то упускаю.

Это не большая проблема для одной машины, но со временем я буду делать это десятки раз, и я хочу найти более простой способ.

И я не один такой. По крайней мере, еще один администратор указал на эту проблему. Автор Zytrax.com: FreeBSD Update Survival Guide: freebsd-update обновление младших или основных версий также говорит об этой ситуации:

Ноты:

1. При обновлении до нового выпуска многое меняется (и тем более с второстепенным выпуском). При изменении файлов сценариев и конфигураций freebsd-update сравнивает их, загружает в vi и представляет для согласования. Поскольку большинство изменений представляют собой простые изменения полей комментариев с номерами версий, это может стать серьезной проблемой (в нашем случае было изменено более 50 файлов, более 40 были изменениями только для комментариев). Однако будьте осторожны - усердие необходимо (нет: wq для каждого файла, не глядя). Кроме того, если файл явно не короткий, необходимо просмотреть и согласовать все метки различий (: / >>> /). В противном случае результирующий файл будет содержать индикаторы различий, и многие важные системные файлы будут просто хрипеть при загрузке (включая файл паролей в нашем случае), что приведет к бесконечным часам удовольствия от поиска файлов, которые были изменены (угадайте, как мы выяснил это). Хотя на самом деле нет альтернативы подлинным изменениям файлов, необходимость проходить согласование редактирования только для комментариев изменений приводит к серьезному недостатку в этом процессе. Возможно, лучше переместить замененные файлы в специальное место и позволить пользователю вручную согласовать интересующие их файлы. Как часто вы меняете /etc/periodic/weekly/310.locate?

Обновить:

Похоже, этими различиями управляет слияние (1), а не слияние. Из справочной страницы merge (1):

   A conflict occurs if both file1 and file3 have changes in a common seg-
   ment of lines.  If a conflict is found, merge normally outputs a  warn-
   ing  and brackets the conflict with <<<<<<< and >>>>>>> lines.  A typi-
   cal conflict will look like this:

      <<<<<<< file A
      lines in file A
      =======
      lines in file B
      >>>>>>> file B