Основы

1. Что такое - CVSup?

   CVSup - пакет программ для передачи и обновления коллекций файлов через сеть. Он состоит из сервера называющегося cvsupd и клиента называемого cvsup.

   CVSup написал Джон Полстра (John Polstra), консультант по программному обеспечению, проживает в Сиэтле.

2. Чем отличается CVSup от других сетевых пакетов коррекции, таких как, например, rdist и sup?

   CVSup более быстрый и более гибкий, чем традиционные пакеты сетевой коррекции.

3. Файлы каких типов могут быть скорректированы, используя CVSup?

   CVSup может эффективно корректировать файлы любых типов. Это могут быть даже ноды Unix-устройств, символические связи и жесткие связи. CVSup поддерживает несколько различных алгоритмов для обновления различных файлов и пытается использовать наиболее эффективный метод для каждого файла. Например, файлы RCS корректируются, используя специализированный алгоритм, который пользуется преимуществом их структуры, чтобы существенно уменьшить время коррекции. Регистрационные файлы (которые изменяются, в конечном счете, только посредством добавления нового текста) корректируются специальным алгоритмом, который передаёт только новый текст. Другие текстовые и двоичные файлы могут быть эффективно скорректированы rsync алгоритмом, который встроен в CVSup.

4. Где я могу получить CVSup?

   CVSup - свободное программное обеспечение, распространяемое по BSD лицензии. Вы можете получить CVSup на ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/, и с FreeBSD-зеркал FTP во всем мире.

   Директория source содержит полные исходные тексты для CVSup. Прочитайте этот текст прежде, чем забирать исходные тексты.

   Мы не поставляем CVSup в виде двоичных дистрибутивов, но любой человек может это сделать это в том случае, если его устроит лицензия в файле License, который поставляется вместе с исходными текстами CVSup.

5. Кому я могу задать вопросы и куда я могу сообщить об ошибках?

   Адрес электронной почты для вопросов и ошибок был изменён для сокрытия от атак спамеров. Вы можете найти его посетив http://www.cvsup.org/contact.html.

   Сообщая о проблеме с CVSup, пожалуйста, укажите как можно больше подробностей. Спецификация:

   • Укажите вывод команды cvsup -v.
   • Укажите вывод команды uname -a на вашей машине-клиенте и, если это возможно, на машине-сервере.
   • Включите в письмо ваш supfile.
   • Включите в письмо "refuse" файлы, если вы их используете.
   • Укажите командную строку, используемую для запуска CVSup.
   • Если CVSup говорит о каких-либо ошибках, укажите эти сообщения.
   • Опишите ваш процесс установки CVSup. Программа была собрана из исходных текстов или вы где-то раздобыли "бинарник"? Если вы используете "бинарник" - укажите каким образом он попал к вам.
   • Если возможно - включите конфигурационные файлы cvsupd.

6. Как следует произносить слово "CVSup"?

   Автор программы произносит как си ви сапп. Это более или менее рифмуется с "beam me up".

Немного Терминологии

7. Что такое RCS файл?

   Файл RCS содержит множество версий единственного исходного файла, всё в одном месте. В течение срока службы проекта, исходные файлы развиваются. Каждый исходный файл имеет начальную версию. Со временем изменения сделаны в исходных файлах, для того чтобы исправить ошибки и добавить новые (:-))) характеристики. В ключевых моментах, программист хочет сохранить текущие версии исходного файла. Он может сделать это с помощью проверки этого файла с соответствующим ему файлом RCS. Из данного файла RCS в последствии может быть извлечена любая желаемая версия исходного файла. Это облегчает как отмену изменений, которые оказались опрометчивыми, так и воссоздание более ранних версий программного обеспечения.

8. Что такое CVS хранилище?

   Хранилище CVS является местом хранения файлов RCS, которые управляются вместе. Например, файлы RCS для всех исходных текстов в проекте должны быть сохранены все вместе в хранилище CVS.

Рецепты

9. Я просто хочу получить самую последнюю версию основного дерева исходных текстов FreeBSD. Что я должен сделать?

   Сделайте cvsupfile, который выглядит приблизительно так:

    *default host=cvsup3.freebsd.org
    *default base=/usr
    *default prefix=/usr
    *default release=cvs
    *default delete use-rel-suffix
    *default tag=.
    src-all
   

   Этот cvsupfile создаст дерево директорий "/usr/src" и заполнит его исходными текстами FreeBSD. Он также создаст дерево "/usr/sup" содержащее файлы checkouts, которые CVSup использует, для поддержки состояния между коррекциями. Если Вы хотите, чтобы ваше дерево исходных текстов располагалось в месте, отличном от "/usr/src", измените описание "prefix=". Если Вы хотите, чтобы файлы checkouts располагались в другом месте (в описании это "/usr/sup"), измените описание "base=".

   Убедитесь в том, что вы не пропустили описание "tag=.". Это описание сообщает CVSup, что следует использовать checkout режим, для получения самой последней версии каждого исходного файла.

10. Когда я устанавливал FreeBSD несколько месяцев тому назад, я установил и исходные тексты. Теперь я хочу использовать CVSup, для того чтобы у меня были исходные тексты в "текущем состоянии". Правильно ли то, что мне следует выбросить(удалить) мои текущие исходные тексты и передать новые исходные тексты по сети заново, используя при этом CVSup?

    Нет, так делать не следует. CVSup способен воспринять существующие у вас исходные тексты и внедрить более новые. Если Вас это заинтересовало, то данная ситуация похожа на ту, как если бы Вы обновляли свои исходные тексты с помощью CVSup, но в конце концов почему-то потеряли ваши файлы checkouts. CVSup использует следующий способ, для того чтобы справиться с обеими ситуациями. CVSup использует контрольные суммы, чтобы определить какие исправленные издания файлов у Вас есть к настоящему времени, а затем корректирует их надлежащим образом, чтобы превратить их в самые последние версии.

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

11. Но Вы сказали выше, что CVSup не удалит файлы, если у меня нет checkouts файлов. Если я принимаю мои существующие файлы, как Вы это описываете, есть ли риск, что некоторые файлы, которые должны быть удалены, не будут удалены?

    Да, так и есть. Версии файлов, которые вы хотите получить, намного новее тех, что вы имеете, и число изменений, которые претерпели новые файлы по сравнению с вашими, слишком велико, поэтому есть большой шанс, что Вы пропустите некоторые важные удаления "ненужных" файлов. К счастью, если Вы приблизительно или точно знаете, какие версии файлов Вы имеете, то Вы можете уменьшить или устранить этот риск. Вы делаете обновление дважды. Сначала, Вы сообщаете CVSup, чтобы он "скорректировал" версии тех файлов, которые Вы уже имеете. Эта процедура не изменит ваших файлов, а всего лишь создаст файлы checkouts, которые точно отражают что Вы имеете к настоящему времени. Следующим шагом Вы корректируете файлы, но на этот раз сообщаете CVSup, какая версия Вам действительно нужна. На втором шаге коррекции, CVSup будет иметь всю информацию, которая ему нужна, для того чтобы знать, какие файлы будут удаляться.

    В этом небольшом трюке есть пара важных деталей, о которых мы всё ещё не упомянули. Итак, мы лучше предоставим Вам пример. Полагаем, что Вы установили FreeBSD-2.2.5, включая исходные тексты с CD-ROM. Теперь Вам захотелось использовать CVSup, чтобы иметь исходные тексты версии 2.2-stable. Для вашей первой коррекции используйте cvsupfile подобный этому:

     *default host=cvsup2.freebsd.org
     *default base=/usr
     *default prefix=/usr
     *default release=cvs
     *default delete use-rel-suffix
     src-all tag=RELENG_2_2_5_RELEASE list=cvs:RELENG_2_2
    

    Для последующих коррекций, измените последнюю строку на:

     src-all tag=RELENG_2_2
    

    Неупомянутые детали в этой последней строке. Прежде всего, где Вы можете узнать какой параметр описания tag следует использовать? Ответ: Вы должны обратиться к списку раздела CVSup главы "Конфигурация" в справочнике FreeBSD для того, чтобы найти список описаний tag, которые можно указать для обновления исходных текстов FreeBSD. Важный момент в том, что описание tag для вашей первой коррекции должно соответствовать версии исходных текстов, которые Вы уже имеете. Описание tag во время вашей второй и последующих коррекций должен соответствовать версии исходных текстов, которые Вы хотите получить.

    Второе, что это за дела с ключевым словом "list"? Это описание используется редко, но это - ситуация где это необходимо использовать. Когда CVSup создает или обращается к одному из своих файлов checkouts, он использует имя файла, который по умолчанию базируется на описаниях "release" и "tag". Обычное имя файла checkouts - "checkouts.RELEASE:TAG", где RELEASE и TAG - это "release" и "tag" установочные параметры в вашем cvsupfile.

    В достаточно специфической ситуации, которую мы описываем здесь, соглашения присваивания имен для файлов checkouts могут вызвать проблему. По умолчанию, наша первая коррекция должна произвести файл названный "checkouts.cvs:RELENG_2_2_5_RELEASE", а вторая коррекция должна найти файл названный "checkouts.cvs:RELENG_2_2". Для того чтобы вторая коррекция принесла пользу с информацией заложенной в первой коррекции, обе коррекции должны использовать один и тот же файл checkouts. Указание атрибута "list" в первом случае позволит нам выполнить именно это. Он аннулирует встроенный суффикс от имени файла checkouts, и заставляет использовать "специальное" имя, которое будет использоваться при последующих коррекциях.

    По всеобщему признанию, это заумно. Но Вы должны сделать это только один раз.

12. Как мне адаптировать мои исходные FreeBSD-2.2.5, и скорректировать их непосредственно в FreeBSD-current?

    Следуйте вышеизложенным инструкциям, но измените src-all строку на нижеследующую. При первой коррекции, используйте:

     src-all tag=RELENG_2_2_5_RELEASE list=cvs:.
    

    При последующих коррекциях, используйте:

     src-all tag=.
    

    Тщательно проверьте описание параметра tag=. Будьте внимательны!

Понимание cvsupfiles

13. Что это за "*default"-подстроки в cvsupfile?

    Здесь нет ничего особенного. Вот cvsupfile:

     *default host=cvsup3.freebsd.org
     *default base=/usr
     *default prefix=/usr
     *default release=cvs
     *default delete use-rel-suffix
     *default tag=.
     src-all
    

    Это описание можно записать и в одну строку:

     src-all host=cvsup3.freebsd.org base=/usr prefix=/usr release=cvs delete use-rel-suffix tag=.
    

    Использование "*default"-подстрок делает ваш cvsupfile более читаемым. Эти подстроки сделают ваш cvsupfile более кратким, если Вы получаете различные наборы файлов.

14. Что делает ключевое слово "delete" в cvsupfile?

    Такая инструкция дает CVSup право удалять файлы на вашей машине. Например, положим у вас есть файл "foo", который Вы первоначально получили, используя CVSup. Теперь владелец сервера удаляет файл "foo". После этого, когда Вы используете CVSup, если опция "delete" определена в вашем cvsupfile, то CVSup удалит файл "foo" на вашей машине. В противном случае CVSup оставит этот файл.

    Вы всегда должны указывать опцию "delete" в вашем cvsupfile, кроме некоторых необычных случаев.

15. Если я всегда должен определять "delete", тогда почему эта опция не выставлена по умолчанию?

    Первоначально CVSup разрабатывался для замены sup. Поэтому, установки по-умолчанию должны иметь такой же смысл.

"Ненужные" Файлы

16. Помогите! Я не могу отказаться от "ненужных" файлов.

    Не огорчайтесь. Многие люди ошибаются. На самом деле эта штука работает.

    Список наиболее частых ошибок, возникающих при работе с файлами-отказниками:

    1. Определение образцов некорректно.
    2. Описания "ненужных" файлов находятся в неправильной директории.
    3. Описаниям "ненужных" файлов даны неправильные имена.

    Мы расскажем об этих проблемах в следующих пунктах.

17. Как мне определить образцы в файле refuse?

    Самое главное - запомнить, что образцы в файлах refuse следует описывать относительно префикса, который чаще всего не является логическим корнем конкретного набора. Для того чтобы определить префикс, посмотрите на ваш cvsupfile. Если он содержит что-то такое:

     *default prefix=/some/directory
    

    то это и будет префикс. В этом случае /some/directory - префикс. В противном случае, префикс - такой же, как и base. Чтобы определить base, прочтите это.

    Как только Вы определили ваш префикс, зайдите в эту директорию. Вычислите относительные маршруты файлов и/или директорий, которые Вы хотите заблокировать, и сделайте образцы, которые сочетаются с префиксом. Установите эти образцы в ваш refuse-файл, разделяя их пробелом. Положите в refuse-файл каждый получившийся образец в отдельной строке или установите разделитель между образцами. Это точно будет работать.

18. Что вы можете сказать о примере файла refuse?

    OK. Полагаем, что Вы используете CVSup, для того, чтобы получить файлы документации FreeBSD (наполнение "doc-all"), используя пример doc-supfile из /usr/share/examples/cvsup. Вот так выглядит cvsupfile (комментарии удалены):

     *default host=CHANGE_THIS.FreeBSD.org
     *default base=/usr
     *default prefix=/usr
     *default release=cvs tag=.
     *default delete use-rel-suffix
     *default compress
     doc-all
    

    Как Вы видите, префиксом является /usr. Относительно него, наполнение "doc-all" устанавливается в поддиректорию doc, который содержит следующие файлы и подкаталоги:

     FAQ/ handbook/ ru_SU.KOI8-R/
     Makefile ja/ sgml/
     en/ ja_JP.EUC/ share/
     en_US.ISO_8859-1/ ja_JP.eucJP/ zh/
     es/ ru/ zh_TW.Big5/
     es_ES.ISO_8859-1/ ru_RU.KOI8-R/
    

    Теперь будем полагать, что Вы не заинтересованы в испанской, японской, русской и тайваньской версиях документации. Итак, Вы хотите отказаться от директорий, имена которых начинаются с "es", "ja", "ru", и "zh". Формируем корректировку относительно префикса:

     doc/es*
     doc/ja*
     doc/ru*
     doc/zh*
    

19. Мой refuse файл работает для директорий, но мне кажется, что я не могу заблокировать индивидуальные файлы.

    Образцы, которые Вы определяете, должны быть похожи на имена файлов на сервере. Если файлы исходят из CVS хранилища (обычный случай), тогда на сервере - файлы RCS. А файлы RCS всегда имеют имена, которые заканчиваются в ",v". Вы должны иметь это в виду.

    Например, полагаем, что Вы захотите заблокировать Makefile в вышеуказанном примере. Образец "doc/Makefile" не будет работать, поскольку на сервере файл имеет имя "doc/Makefile,v". Правильный образец, чтобы использовать,

     doc/Makefile,v
    

    или (что лучше)

     doc/Makefile*
    

    Имя файла на сервере удовлетворяет последнему образцу независимо от того, файл RCS там или нет.

20. Почему мой refuse файл блокирует некоторые файлы, образцы которых не содержатся ни в одном из файлов?

    Возможно вы попытались добавить комментарий в ваш refuse файл. Но (сюрприз!) refuse файлы не понимают комментарии. Этот ваш "комментарий" воспринимается за шаблоны, которые содержатся в именах файлов, получаемых вами.

    Вот как выглядит неправильный refuse файл:

     # Мы принимаем всё (src и ports), исключая games
     src/games
    

    Эта безвредно выглядящая строка не комментарий. Это один из 13 шаблонов, включая "#", "src", и "ports". Это скорее всего то, что вы искали.

    Может быть когда-нибудь добавить комментарий станет возможно, но сейчас это запрещено.

21. Где я должен установить мои refuse файлы?

    Сначала Вы должны определить вашу директорию base.

    1. Когда Вы выполняете программу "cvsup", используете ли Вы опцию "-b pathname"? (Большинство пользователей не используют.) Если да, то - pathname является base. В противном случае...

    2. Содержит ли Ваш cvsupfile спецификацию "base=pathname"? (У многих именно так.) Если да, то pathname является base. В противном случае...

    3. base - встроено по умолчанию, "/usr/local/etc/cvsup".

    Затем Вы должны определить collDir, поддиректорию base, где CVSup ведёт историю ваших наборов.

    1. Когда Вы исполняете программу "cvsup", используете ли Вы опцию "-c directory"? (Обычно нет.) Если да, то directory является collDir. В противном случае...
    2. У вас collDir - встроено по умолчанию, т.е. "sup".

    Наконец, Вы должны знать имя набора, который Вы хотите ограничить, например, "doc-all".

    Объедините эти три пункта с разделителем, напишите "refuse" в конце. Здесь и следует держать файл refuse. Пример, которым воспользовались, работает с

     /usr/sup/doc-all/refuse
    

    только тогда, когда Вы не используете опции "-b" или "-c".

22. Можно ли создать глобальный файл refuse, который будет относиться ко всем наборам?

    Да. Просто пропустите имя набора и разделитель "/", когда Вы формулируете имя файла. В предшествующем примере, глобальный файл refuse должен быть

     /usr/sup/refuse
    

CVSup и Firewall'ы

23. Как мне заставить работать CVSup, через мой TIS FWTK firewall?

    Следуйте инструкции, любезно предоставленной Alan Strassberg:

    1. Добавьте следующую строку к /etc/services:

        cvsup 5999/tcp # CVSup
       

    2. Следующую строку добавьте в /etc/inetd.conf:

        cvsup stream tcp nowait root /usr/local/etc/plug-gw plug-gw cvsup
       

       и пошлите сигнал SIGHUP демону inetd.

       # kill -HUP `ps ax | grep inetd | grep -v grep | awk '{ print $1; }'`
       

    3. Добавьте следующую строку к /usr/local/etc/netperm-table (или другому файлу в зависимости от вашей системы):

        plug-gw: port cvsup A.B.C.D -plug-to W.X.Y.Z -port cvsup
       

       где A.B.C.D - IP адрес внутренней машины, а W.X.Y.Z - IP адрес CVSup сервера.

    4. Скажите в вашем cvsupfile, что CVSup сервер, это ваш firewall:

        *default host=gatekeeper.foo.com
       

    5. Когда Вы запускаете cvsup, добавьте опции "-P m" в командной строке.

    Диагностика: Запустите telnet с машины из внутренней сети на firewall:5999 и вы увидите приветствие сервера CVS:

     % telnet gatekeeper.foo.com 5999
     OK 15 5 REL_15_4_2 CVSup server ready
    

    Если приветствие не появляется, выполните netstat -na на firewall и проверьте, слушает ли он порт 5999:

     % netstat -na | grep 5999
     ...
     tcp 0 0 *.5999 *.* LISTEN
     

Проблемы при использовании CVSup

24. Почему CVSup вдруг начинает выдавать мне массу сообщений, таких как "Checksum mismatch -- will transfer entire file" ("несовпадение контрольной суммы - файл будет передан полностью")? Каждый файл получает "fixup", и это действительно замедляет коррекцию моих наборов файлов.

    Вам и вашему дружественному (:-))) администратору сервера следует модернизировать CVSup до версии 15.4 или более поздней. Это решит эту проблему.

    CVSup модернизирует файл RCS следующим образом: деконструирует этот файл на сервере, посылает изменившиеся части клиенту, и восстанавливает файл на стороне клиента. (Это похоже на транспортер на предприятии межзвездных кораблей). Затем CVSup сравнивает MD5-контрольную сумму восстановленного файла с подлинником на сервере, чтобы убедиться, что процесс отработал правильно.

    К несчастью, последние версии CVS ввели некоторые безвозвратные изменения в формат файлов RCS. Эти изменения касаются пробелов, которые никак не отражаются на логическом значении файла. Тем не менее, как результат, файл RCS, созданный CVSup-клиентом не соответствует побайтно исходному файлу. Даже если восстановленный файл логически идентичен подлиннику, он имеет другую контрольную сумму. Более старые версии CVSup отвергали скорректированный файл и использовали fixup, для того чтобы вновь передать файл целиком.

    Для решения этой проблемы, в CVSup 15.4 введено понятие логической контрольной суммы, которая используется только для RCS-файлов. Вместо слепой побайтной обработки контрольной суммы над целым файлом, новый алгоритм контрольной суммы тщательно канонизирует файл так, что несоответствующие различия интервала проигнорированы. Логическая контрольная сумма должна сделать CVSup устойчивым к любым возможным проблемах этого рода.

25. Когда я пытаюсь запустить CVSup, он сообщает мне о подключении к серверу, но потом просто виснет. В чем дело?

    Скорее всего, Вы находитесь за firewall, который блокирует попытки CVSup-сервера установить второе TCP-соединение к вашему клиенту. Добавьте опцию "-P m" в командную строку cvsup, и все должно заработать.

26. Всякий раз, когда я запускаю CVSup под FreeBSD, я получаю огромное количество сообщений, подобных этому: fatal process exception: page fault, fault VA = 0x11a610.

    Когда Вы собирали ядро для FreeBSD, Вы включили недокументированную "options DEBUG" в конфигурационный файл. Больше так не делайте.

27. Я попытался запустить исполняемый файл CVSup-клиента для FreeBSD под BSD/OS, но он падает в core. Почему он не работает?

    Да, статически слинкованные исполняемые файлы FreeBSD работают на других *BSD операционных системах. Но на некоторых из них, включая BSD/OS, Вы должны добавить "@M3novm" в командной строке.

    CVSup написан на Modula-3, и система использует умный мусорщик, который использует захваты в подсистему VM операционной системы, чтобы приобрести лучшее диалоговое исполнение. Эта характеристика спотыкается на несовместимости между BSD/OS и FreeBSD, вызывая падение в core. Загадочный аргумент "@M3novm" исключает захваты VM, что и делает возможным выполнять исполняемые файлы FreeBSD под другими BSD-подобными операционными системами.

    Также, последние версии (4.0 и более поздние) BSD/OS не могут запускать бинарные файлы FreeBSD в формате ELF. Но они могут выполнять старые файлы формата a.out без каких-либо проблем.

28. CVSup-клиент умирает с сообщением о нарушении целостности (segmentation violation) когда я пытаюсь использовать ГПИ (aka GUI).

    Сообщение выглядит так?

     
     ***
     *** runtime error:
     *** Segmentation violation - possible attempt to dereference NIL
     *** pc = 0x81f0708 = Cat + 0x18 in /b/jdp/pm3/pm3/libs/m3core/src/text/Text.m3
     *** 
     use option @M3stackdump to get a stack trace
     Abort trap (core dumped)
    

    Это ошибка в графической библиотеке Modula-3, которая сообщает о неправильной настройке DNS. Если говорить детально, ошибка говорит об отсутствии реверсивной записи в DNS вашего IP адреса. Попробуйте выполнить нижеследующие команды для проверки установок DNS. (Если в вашей системе отсутствует команда "host", используйте "dig" или "nslookup".)

     
     $ hostname
     bogus.example.com
     
     $ host bogus.example.com
     bogus.example.com has address 192.168.1.1
     
     $ host 192.168.1.1
     Host not found, try again.
    

    Последняя строка указывает на проблему. Если ваш DNS установлен правильно, вы должны увидеть следующее

     
     1.1.168.192.IN-ADDR.ARPA domain name pointer bogus.example.com
    

    Правильный путь для устранения этой проблемы - исправить установки DNS. (Соответствующие рекомендации вы можете получить у системного администратора.) Если это невозможно, вы можете устранить эту проблему добавив строку в ваш "/etc/hosts" файл. И всё-таки, если эту проблему невозможно устранить, запустите CVSup клиента без ГПИ (aka GUI) добавив "-g" в командной строке.

    Когда-нибудь я устраню эту проблему в графической библиотеке.

29. Исполняемый файл для Linux с CVSup ftp-сервера не может выполнить запрос к DNS на моей Linux системе.

    Проверьте FTP сервер ещё раз на предмет новых исполняемых файлов. Эта проблема возникает ввиду несовместимости между некоторыми Linux ядрами и некоторыми версиями glibc. Новая версия (распространяется начиная с 20 февраля 2000 года) динамически слинкована с C библиотекой, и она должна работать на разных версиях Linux.

30. CVSup (как клиент, так и сервер) умирают с сообщением "gc: Could not extend the traced heap".

    Это странное, на первый взгляд, сообщение говорит вам о том, что памяти не хватает. Попробуйте уточнить лимиты на ресурсы и сделать их побольше. В шеллах, порождённых от sh, используйте "ulimit -Sa" для уточнения параметров "datasize" и "memoryuse". В шеллах, порождённых от csh, используйте команду "limit" для проверки параметров "data seg size" и "max memory size".

31. CVSup клиент периодически умирает ввиду выхода за пределы DragonInt.m3

    Это ошибка в исходных текстах Modula-3 runtime. Заберите новый исполняемый файл с CVSup FTP-сервера. Или используйте это исправление для ваших исходных текстов Modula-3, затем пересоберите и переустановите Modula-3.

    Для быстрого устранения проблемы просто запустите CVSup клиента без ГПИ (aka GUI) добавив "-g" в командной строке.

32. Я переместил CVSup зеркало, которым я управляю, на другую ОС и теперь CVSup (клиент и/или сервер) постоянно падают.

    Если вы переместили ваш сайт с таким платформ как FreeBSD, NetBSD, OpenBSD или BSD/OS на не-BSD систему, проблема в файлах отладки ("checkouts"), о которых вы уже слышали. Они содержат некоторую информацию которую не-BSD версии CVSup'а не поддерживают. Эта фишка - ошибка и она присутствует в версиях 16.1 и ниже. Эта ошибка будет исправлена и эта проблема устранится начиная с версии 16.2. До той поры, вам проще обойти эту проблему путём удаления "checkouts*" файлов из вашей base директории, что заставит CVSup переделать эти файлы.

33. Иногда, когда я запускаю CVSup клиента, он выдаёт сообщение "SetAttrs" на каждом файле.

    Обычно такое происходит, когда CVSup думает, что следует изменить один или несколько атрибутов файла (права владельца, группы, разрешения и т.п.) но не может этого сделать. Атрибуты файла могут быть неправильными, или записи в файле отладки ("checkouts") могут быть неверными. Проверьте следующее:

    • Вы иногда выполняете изменения от пользователя root (например, из cron'а), а другие изменения вы производите от другого пользователя. Во время исправления от пользователя root, владельцем файла становится root. А позднее, вы под другим пользователем исправляете эти файлы.

    • Вы, используя различные установки umask, иногда запускаете CVSup. Простой выход обновить версию CVSup. Добавьте "*default umask=2" (pick your desired value) в начало вашего supfile.

    • Ваши файлы отладки ("checkouts") в каталоге "base" имеет разрешения, запрещающие CVSup'у писать в них.

34. Я попытался скорректировать мои файлы с помощью CVSup, но все что я получил, это мешок (вагон и маленькая тележка:-) странно выглядящих файлов, чьи имена заканчиваются на ",v". Почему?

    Эти странные файлы - файлы RCS, и CVSup прислал их Вам, поскольку ваш cvsupfile сообщил ему об этом. Когда Вы просите CVSup прислать Вам коррекции из CVS-хранилища, есть две абсолютно разные вещи, которые Вы можете потребовать. Во-первых, Вы можете попросить исходные файлы, которые должны извлекаться из хранилища и посылаться Вам. Это, очевидно, то, что Вы хотели. Во-вторых, Вы можете потребовать "сырые" файлы RCS (содержащие все версии исходных текстов), которые также могут быть присланы Вам.

    Эти два режима функционирования коренным образом различаются. Оба работают на основе RCS-файлов в CVS-хранилище на стороне сервера. Но они используют RCS-файлы по-разному. Первый режим называется "checkout режим": вызывается конкретная версия исходных текстов из файлов RCS, и эта версия посылается Вам. Второй режим называется "режим CVS". В этом режиме Вам посылаются сами файлы RCS, в той же форме, как и на сервере. В cvsupfile, ключевые слова "tag" и "date" контролируют выбранный вами режим. Если любое из этих ключевых слов присутствует, то CVSup использует checkout режим, чтобы прислать Вам комплект исходных файлов. Если и "tag", и "date" отсутствуют, то CVSup использует режим CVS, чтобы послать Вам файлы RCS.

    Если вы хотите получить самые последние версии файлов, то вам следует добавить ключевое слово "tag=." в ваш supfile.

35. CVSup неожиданно начал устанавливать дату на изменённых файлах в 1970 год!

    Дело в ошибке, до этого момента находящейся в летаргическом сне. Эта ошибка присутствует во всех версиях до SNAP_16_1d. Вам необходимо обновить как клиентскую, так и серверную части до версии SNAP_16_1d для того, чтобы устранить эту проблему. (Новые версии, которые будут выпущены после SNAP_16_1d, будут содержать исправление этой ошибки.) Подробности и дистрибутив SNAP_16_1d, как в исходных текстах, так и бинарной форме, вы можете получить посетив http://people.freebsd.org/~jdp/s1g/.

Файлы отладки

36. Что такое файлы отладки (checkouts), о которых я тут слышал?

    Для эффективной корректировки ваших файлов, CVSup должен знать что Вы хотите получить. Он загружает эту информацию в так называемые файлы "отладки" (checkouts). Всякий раз, когда Вы запускаете cvsup, он читает эти файлы, чтобы увидеть какие файлы (и какие исправленные версии этих файлов) Вы имеете. Как только он корректирует ваши файлы, он также корректирует и информацию в checkouts-файлах.

    Также checkouts-файлы иногда именуются как "списки" файлов.

37. Всё это страшно. Что если я случайно удалю один из файлов отладки?

    Это небольшая проблема. Если CVSup не cможет найти checkout-файл, который ему нужен, он перейдёт к другим методам определения ваших файлов. Один из методов состоит в вычислении контрольных сумм (файловых подписей MD5) для каждого из ваших файлов, и использовании этих контрольных сумм, для вычисления какие исправленные версии файлов Вы имеете. Это действие вполне безопасное, но неэффективное. Оно замедляет скорость коррекции, а также серьёзно загружает сервер.

38. Что если мои файлы отладки каким-то образом исказятся?

    CVSup обнаружит проблему и завершит свою работу с предложением удалить повреждённый файл, а после этого снова попытаться запустить CVSup. Если Вы последуете этому предложению, он завершит вашу коррекцию, используя методы аварийного перехода, упомянутые выше, и воссоздаст ваш checkout-файл для следующего раза.

39. А что ещё "неправильного" может произойти, если я потеряю файлы отладки?

    Есть ещё одна вещь, которая может произойти, но это не очень существенно. CVSup удалит лишь файлы, которые указаны в его checkouts-файле. Таким образом, если Вы потеряете ваш checkouts-файл, а затем файл "foo" удаляется на стороне сервера, то после выполнения CVSup, ваш файл "foo" не будет удален.

    Файл никогда не будет удалён из CVS-хранилища, но, в действительности, это несущественно. Чтобы быть уверенным в полной мере, Вы должны выполнить CVSup как можно раньше, т.е. как только Вы узнали о потере checkouts-файла, немедленно приступите к процедуре коррекции.

Локальные изменения в вашем CVS хранилище

40. Могу ли я как-то отслеживать мои собственные изменения в CVS хранилище, когда я произвожу накат из главного хранилища?

    Если вы осторожны и если вы понимаете что происходит за сценой, вы можете сделать это. CVSup разрабатывался для локальных проверок в соответствии с RCS файлами, взятыми из основного хранилища. Поскольку CVSup понимает структуру RCS файлов, он может произвести новые исправленные издания с сервера, не мешая вашим собственным исправленным изданиям, которые Вы изменили у себя. К несчастью, определённые логические вопросы делают эту возможность неудобной, для того, чтобы использовать её в практических ситуациях.

    Для сохранения локальных исправленных версий в вашей копии хранилища CVS, Вы должны:

    • Указать CVSup не удалять их.
    • Гарантировать, что номера версий ваших локальных исправлений не противоречат номерам текущих или будущих исправлений каждого RCS файла на сервере.

    Ниже мы расскажем как это можно сделать.

41. Как мне удержать CVSup от удаления локально исправленных изданий?

    Просто удалите ключевое слово "delete" из вашего cvsupfile. Присутствие этого ключа даёт CVSup право удалять исправления из RCS файлов. Также этот ключ разрешает CVSup удалять целиком файлы RCS, при условии, что он создаст их заново. Если вы уберёте ключ "delete", вы предохранитесь от удаления CVSup'ом локально исправленных изданий, а также RCS файлов. Тем не менее, очень важно понимать последствия удаления ключевого слова "delete".

    Сначала, положим, что один из множества RCS файлов был удалён из хранилища CVS на стороне главного сервера. Без ключа "delete" CVSup не сможет удалить соответствующий файл в вашей локальной копии. Таким образом Вы будете иметь некоторые файлы RCS в вашем хранилище, которых, в противном случае, там не было бы.

    В идеальном мире, это не проблема. Потому что, в идеальном мире никто не удаляет RCS файл из CVS хранилища. Таким образом, такая ситуация не должна возникать никогда.

    К несчастью, большинство администраторов управляют своим хранилищем не так идеально, как хотелось бы. Коммиттеры, совершая ошибки, оставляют файлы не там, где следует. Большинство администраторов вручную исправляют такие ошибки, перемещая файлы в хранилище, но некоторые ошибки продолжают жить. Другой пример, в любом большом хранилище, некоторые файлы в конечном счете становятся полностью устаревшими. В итоге, разработчики пожалуются на отсутствие дискового пространства и бардак в хранилище, и администратор хранилища, в ответ на их запрос, удалит файлы.

    Обычно, восстановленные RCS файлы не вызывают никаких проблем и их можно благополучно игнорировать. Это особенно верно если администратор хранилища основного сервера был осторожным, чтобы выделить "мёртвые" файлы на всех ветках с выполнением команды "cvs remove" на несколько недель раньше, чем полностью удалить нежелательные файлы RCS. Тем не менее, дополнительные файлы RCS могут вызвать проблемы в некоторых случаях, и Вы должны знать об этом.

42. Как мне защитить исправленные издания моих локальных регистраций от противоречий с номерами исправленных изданий, порождающимися на основном сервере?

    Это трудно, поскольку CVS выбирает очередной номер версии сам. Один из путей - немного исправить CVS. Прежде, чем обсуждать это, создайте новую ветку, где вы будете держать ваши локальные изменения. Не пытайтесь проверить ваши локальные изменения в основной ветке или в ветке, которая существует в основном хранилище. Если вы так сделаете, то, скорее всего, рано или поздно, возникнут коллизии.

    Если ваши локальные исправленные издания находятся на своей собственной ветке, то проблема сводится к гарантии, что ваша ветка имеет уникальный номер исправленного издания, который никогда не задублируется с номером в основном хранилище. Наилегчайший путь - модифицировать CVS. Версия CVS (в составе дистрибутива FreeBSD) включает такую модификацию. В этой версии, Вы можете влиять на номера исправленных изданий ответвлений, устанавливая внешнюю переменную CVS_LOCAL_BRANCH_NUM.

    Эта переменная должна устанавливаться в целое, и CVS будет использовать её, как отправной пункт, выбирая номер для исправленного издания в новых ветках. По умолчанию, CVS распределяет отраслевые номера начинаемые с 1. Следовательно, много большее число, как например, 1000 - хороший выбор. Новые ветки получат меньшие номера, когда ваши собственные локальные ветки получат большие номера исправленного издания. Таким образом эти ветки не будут противоречить друг другу.

    Используя этот метод, коммиттеры не должны устанавливать CVS_LOCAL_BRANCH_NUM создавая ветки в основном хранилище.

    Если у Вас нет версии CVS, которая поддерживает CVS_LOCAL_BRANCH_NUM, то можно избежать конфликтов с помощью сотрудничества с основным сервером. Просто создайте ветку в основном хранилище, объявите что, она зарезервирована для локальных модификаций, и не используйте её в основном хранилище.

Установка CVSup сервера

43. Как мне определить простой набор для тестирования CVSup сервера?

    Создайте где-нибудь пустую директорию. Мы будем называть её base. Зайдите в baseи выполните команду mkdir -p sup/test.

    Затем, зайдите в sup/test и создайте файл с названием releases с единственной строкой, такой как эта:

     cvs list=list.cvs prefix=prefix
    

    В дальнейшем, замените prefix на абсолютный путь к некоторому хранилищу CVS на вашей машине, /usr/cvs. Если у Вас нет хранилища CVS, вы можете использовать любую директорию, содержащую несколько файлов. Но RCS файлы - лучшее средство для тестирования.

    В директории, где находится файл releases, создайте файл list.cvs. В нём должна содержаться единственная строка:

     upgrade src/bin
    

    Здесь, замените src/bin на некоторый путь к поддереву вашего хранилища CVS, родственному с prefix. Например, если prefix это /usr/cvs в вашем releases файле, и строка в list.cvs такая, как было сказано выше, то поддерево, которое можно будет "забрать", имеет вершину /usr/cvs/src/bin.

    Вы только что создали коллекцию CVSup "test" c release названием "cvs". Вы можете запустить сервер так:

     cvsupd -b base
    

    заменив base на путь к base директории, которая была создана ранее. Если Вы сделали всё правильно, то cvsupd будет печатать сообщения на stdout, обслужит одного клиента и завершит работу. Для нескольких тестирований подряд, Вам придётся рестартовать сервер несколько раз. Альтернативный путь, запустить сервер так:

     cvsupd -b base -C 1 -l /dev/stdout
    

    Сервер станет даймоном и будет обслуживать клиентов до тех пор, пока Вы собственноручно его не убьёте. Замечание, местонахождение рабочей директории не зависит от места запуска сервера.

    Сейчас, Вы можете создать отдельную пустую директорию для запуска клиента, для получения дополнений с сервера. Мы назовём эту директорию dest. В dest, создайте файл supfile, который будет выглядеть так:

     *default host=localhost
     *default base=.
     *default release=cvs
     *default delete use-rel-suffix
     test
    

    (Замечу, что здесь "." в "base=.".) Проверяем, что сервер запущен, а затем, находясь в dest