| Каталог документации / Раздел "Руководства по FreeBSD на русском" | (Архив | Для печати) |
| ||
|
Спасибо Сергею Осокину, теперь также доступна и русская версия!
CVSup - пакет программ для передачи и обновления коллекций файлов через сеть. Он состоит из сервера называющегося cvsupd и клиента называемого cvsup.
CVSup написал Джон Полстра (John Polstra), консультант по программному обеспечению, проживает в Сиэттле.
CVSup более быстрый и более гибкий, чем традиционные пакеты сетевой коррекции.
CVSup может эффективно корректировать файлы любых типов. Это могут быть даже ноды Unix-устройств, символические связи и жесткие связи. CVSup поддерживает несколько различных алгоритмов для обновления различных файлов и пытается использовать наиболее эффективный метод для каждого файла. Например, файлы RCS корректируются, используя специализированный алгоритм, который пользуется преимуществом их структуры, чтобы существенно уменьшить время коррекции. Регистрационные файлы (которые изменяются, в конечном счете, только посредством добавления нового текста) корректируются специальным алгоритмом, который передаёт только новый текст. Другие текстовые и двоичные файлы могут быть эффективно скорректированы rsync алгоритмом, который встроен в CVSup.
CVSup - свободное программное обеспечение, распространяемое по BSD лицензии. Вы можете получить CVSup на ftp://ftp3.FreeBSD.org/pub/FreeBSD/development/CVSup/, и с FreeBSD-зеркал FTP во всем мире.
В source директории содержит полные исходные тексты для CVSup. Прочитайте этот текст прежде, чем забирать исходные тексты.
Директория binaries содержит статически скомпилированные модули для различных платформ:
Обязательно прочтите соответствующий файл README для вашей платформы.
Пожалуйста, адресуйте всю почту относительно CVSup на cvsup-bugs@polstra.com.
Сообщая о проблеме с CVSup, пожалуйста, укажите как можно больше подробностей. Спецификация:
Автор программы произносит как си ви сапп. Это более или менее рифмуется с "beam me up".
Файл RCS содержит множество версий единственного исходного файла, всё в одном месте. В течение срока службы проекта, исходные файлы развиваются. Каждый исходный файл имеет начальную версию. Со временем изменения сделаны в исходных файлах, для того чтобы исправить ошибки и добавить новые (:-))) характеристики. В ключевых моментах, программист хочет сохранить текущие версии исходного файла. Он может сделать это с помощью проверки этого файла с соответствующим ему файлом RCS. Из данного файла RCS в последствии может быть извлечена любая желаемая версия исходного файла. Это облегчает как отмену изменений, которые оказались опрометчивыми, так и воссоздание более ранних версий программного обеспечения.
Хранилище CVS является местом хранения файлов RCS, которые управляются вместе. Например, файлы RCS для всех исходных текстов в проекте должны быть сохранены все вместе в хранилище CVS.
Да, попробуйте пакет "cvsupit" от Jordan Hubbard. Вы можете найти этот пакет здесь: ftp://ftp3.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz.
Сделайте 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 режим, для получения самой последней версии каждого исходного файла.
Нет, так делать не следует. CVSup способен воспринять существующие у вас исходные тексты и внедрить более новые. Если Вас это заинтересовало, то данная ситуация похожа на ту, как если бы Вы обновляли свои исходные тексты с помощью CVSup, но в конце концов почему-то потеряли ваши файлы checkouts. CVSup использует следующий способ, для того чтобы справиться с обеими ситуациями. CVSup использует контрольные суммы, чтобы определить какие исправленные издания файлов у Вас есть к настоящему времени, а затем корректирует их надлежащим образом, чтобы превратить их в самые последние версии.
Следуйте нашим дальнейшим инструкциям для того, чтобы узнать, как это сделать более безопасно.
Да, так и есть. Версии файлов, которые вы хотите получить, намного новее тех, что вы имеете, и число изменений, которые претерпели новые файлы по сравнению с вашими, слишком велико, поэтому есть большой шанс, что Вы пропустите некоторые важные удаления "ненужных" файлов. К счастью, если Вы приблизительно или точно знаете, какие версии файлов Вы имеете, то Вы можете уменьшить или устранить этот риск. Вы делаете обновление дважды. Сначала, Вы сообщаете 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, и заставляет использовать "специальное" имя, которое будет использоваться при последующих коррекциях.
По всеобщему признанию, это заумно. Но Вы должны сделать это только один раз.
Следуйте вышеизложенным инструкциям, но измените src-all строку на нижеследующую. При первой коррекции, используйте:
src-all tag=RELENG_2_2_5_RELEASE list=cvs:.
При последующих коррекциях, используйте:
src-all tag=.
Тщательно проверьте описание параметра tag=. Будьте внимательны!
Эдесь нет ничего особенного. Вот 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 более кратким, если Вы получаете различные наборы файлов.
Такая инструкция дает CVSup право удалять файлы на вашей машине. Например, положим у вас есть файл "foo", который Вы первоначально получили, используя CVSup. Теперь владелец сервера удаляет файл "foo". После этого, когда Вы используете CVSup, если опция "delete" определена в вашем cvsupfile, то CVSup удалит файл "foo" на вашей машине. В противном случае CVSup оставит этот файл.
Вы всегда должны указывать опцию "delete" в вашем cvsupfile, кроме некоторых необычных случаев.
Первоначально CVSup разрабатывался для замены sup. Поэтому, установки по-умолчанию должны иметь такой же смысл.
Не огорчайтесь. Многие люди ошибаются. На самом деле эта штука работает.
Список наиболее частых ошибок, возникающих при работе с файлами-отказниками:
Мы расскажем об этих проблемах в следующих пунктах.
Самое главное - запомнить, что образцы в файлах refuse следует описывать относительно префикса, который чаще всего не является логическим корнем конкретного набора. Для того чтобы определить префикс, посмотрите на ваш cvsupfile. Если он содержит что-то такое:
*default prefix=/some/directory
то это и будет префикс. В этом случае /some/directory - префикс.
В противном случае, префикс - такой же, как и base. Чтобы определить base,
прочтите это.
Как только Вы определили ваш префикс, зайдите в эту директорию. Вычислите относительные маршруты файлов и/или директорий, которые Вы хотите заблокировать, и сделайте образцы, которые сочетаются с префиксом. Установите эти образцы в ваш refuse-файл, разделяя их пробелом. Положите в 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*
Образцы, которые Вы определяете, должны быть похожи на имена файлов на сервере. Если файлы исходят из CVS хранилища (обычный случай), тогда на сервере - файлы RCS. А файлы RCS всегда имеют имена, которые заканчиваются в ",v". Вы должны иметь это в виду.
Например, полагаем, что Вы захотите заблокировать Makefile в вышеуказанном примере. Образец "doc/Makefile" не будет работать, поскольку на сервере файл имеет имя "doc/Makefile,v". Правильный образец, чтобы использовать,
doc/Makefile,v
или (что лучше)
doc/Makefile*
Имя файла на сервере удовлетворяет последнему образцу независимо от того, файл RCS там или нет.
Возможно вы попытались добавить комментарий в ваш refuse файл. Но (сюрприз!) refuse файлы не понимают комментарии. Этот ваш "комментарий" воспринимается за шаблоны, которые содержатся в именах файлов, получаемых вами.
Вот как выглядит неправильный refuse файл:
# Мы принимаем всё (src и ports), исключая games
src/games
Эта безвредно выглядящая строка не комментарий. Это
один из 13 шаблонов, включая "#", "src", и "ports". Это
скорее всего то, что вы искали.
Может быть когда-нибудь добавить комментарий станет возможно, но сейчас это запрещено.
Сначала Вы должны определить вашу директорию base.
Затем Вы должны определить collDir, поддиректорию base, где CVSup ведёт историю ваших наборов.
Наконец, Вы должны знать имя набора, который Вы хотите ограничить, например, "doc-all".
Объедините эти три пункта с разделителем, напишите "refuse" в конце. Здесь и следует держать файл refuse. Пример, которым воспользовались, работает с
/usr/sup/doc-all/refuseтолько тогда, когда Вы не используете опции "-b" или "-c".
Да. Просто пропустите имя набора и разделитель "/", когда Вы формулируете имя файла. В предшествующем примере, глобальный файл refuse должен быть
/usr/sup/refuse
Следуйте инструкции, любезно предоставленной Alan Strassberg:
cvsup 5999/tcp # CVSup
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; }'`
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 сервера.
*default host=gatekeeper.foo.com
Диагностика: Запустите 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 до версии 15.4 или более поздней. Это решит эту проблему.
CVSup модернизирует файл RCS следующим образом: деконструирует этот файл на сервере, посылает изменившиеся части клиенту, и восстанавливает файл на стороне клиента. (Это похоже на транспортер на предприятии межзвездных кораблей). Затем CVSup сравнивает MD5-контрольную сумму восстановленного файла с подлинником на сервере, чтобы убедиться, что процесс отработал правильно.
К несчастью, последние версии CVS ввели некоторые безвозвратные изменения в формат файлов RCS. Эти изменения касаются пробелов, которые никак не отражаются на логическом значении файла. Тем не менее, как результат, файл RCS, созданный CVSup-клиентом не соответствует побайтно исходному файлу. Даже если восстановленный файл логически идентичен подлиннику, он имеет другую контрольную сумму. Более старые версии CVSup отвергали скорректированный файл и использовали fixup, для того чтобы вновь передать файл целиком.
Для решения этой проблемы, в CVSup 15.4 введено понятие логической контрольной суммы, которая используется только для RCS-файлов. Вместо слепой побайтной обработки контрольной суммы над целым файлом, новый алгоритм контрольной суммы тщательно канонизирует файл так, что несоответствующие различия интервала проигнорированы. Логическая контрольная сумма должна сделать CVSup устойчивым к любым возможным проблемах этого рода.
Скорее всего, Вы находитесь за firewall, который блокирует попытки CVSup-сервера установить второе TCP-соединение к вашему клиенту. Добавьте опцию "-P m" в командную строку cvsup, и все должно заработать.
Когда Вы собирали ядро для FreeBSD, Вы включили недокументированную "options DEBUG" в конфигурационный файл. Больше так не делайте.
Да, статически слинкованные исполняемые файлы 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 без каких-либо проблем.
Сообщение выглядит так?
***
*** 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"
в командной строке.
Когда-нибудь я устраню эту проблему в графической библиотеке.
Проверьте FTP сервер ещё раз на предмет новых исполняемых файлов. Эта проблема возникает ввиду несовместимости между некоторыми Linux ядрами и некоторыми версиями glibc. Новая версия (распространяется начиная с 20 ферваля 2000 года) динамически слинкована с C библиотекой, и она должна работать на разных версиях Linux.
Это странное, на первый взгляд, сообщение говорит вам о том, что памяти не хватает. Попробуйте уточнить лимиты на ресурсы и сделать их побольше. В шеллах, порождённых от sh, используйте "ulimit -Sa" для уточнения параметров "datasize" и "memoryuse". В шеллах, порождённых от csh, используйте команду "limit" для проверки параметров "data seg size" и "max memory size".
Это ошибка в исходных текстах Modula-3 runtime. Заберите новый исполняемый файл с CVSup FTP-сервера. Или используйте это исправление для ваших исходных текстов Modula-3, затем пересоберите и переустановите Modula-3.
Для быстрого устранения проблемы просто запустите CVSup клиента без ГПИ (aka GUI) добавив "-g" в командной строке.
Если вы переместили ваш сайт с таким платформ как FreeBSD, NetBSD, OpenBSD или BSD/OS на не-BSD систему, проблема в файлах отладки ("checkouts"), о которых вы уже слышали. Они содержат некоторую информацию которую не-BSD версии CVSup'а не поддерживают. Эта фишка - ошибка и она присутствует в версиях 16.1 и ниже. Эта ошибка будет исправлена и эта проблема устранится начиная с версии 16.2. До той поры, вам проще обойти эту проблему путём удаления "checkouts*" файлов из вашей base директории, что заставит CVSup переделать эти файлы.
Обычно такое происходит, когда CVSup думает, что следует изменить один или несколько аттрибутов файла (права владельца, группы, разрешения и т.п.) но не может этого сделать. Аттрибуты файла могут быть неправильными, или записи в файле отладки ("checkouts") могут быть неверными. Проверьте следующее:
Эти странные файлы - файлы 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.
Дело в ошибке, до этого момента находящейся в летаргическом сне. Эта ошибка присутствует во всех версиях до SNAP_16_1d. Вам необходимо обновить как клиентскую, так и серверную части до версии SNAP_16_1d для того, чтобы устранить эту проблему. (Новые версии, которые будут выпущены после SNAP_16_1d, будут содержать исправление этой ошибки.) Подробности и дистрибутив SNAP_16_1d, как в исходных текстах, так и бинарной форме, вы можете получить посетив http://people.freebsd.org/~jdp/s1g/.
Для эффективной корректировки ваших файлов, CVSup должен знать что Вы хотите получить. Он загружает эту информацию в так называемые файлы "отладки" (checkouts). Всякий раз, когда Вы запускаете cvsup, он читает эти файлы, чтобы увидеть какие файлы (и какие исправленные версии этих файлов) Вы имеете. Как только он корректирует ваши файлы, он также корректирует и информацию в checkouts-файлах.
Также checkouts-файлы иногда именуются как "списки" файлов.
Это небольшая проблема. Если CVSup не cможет найти checkout-файл, который ему нужен, он перейдёт к другим методам определения ваших файлов. Один из методов состоит в вычислении контрольных сумм (файловых подписей MD5) для каждого из ваших файлов, и использовании этих контрольных сумм, для вычисления какие исправленные версии файлов Вы имеете. Это действие вполне безопасное, но неэффективное. Оно замедляет скорость коррекции, а также серьёзно загружает сервер.
CVSup обнаружит проблему и завершит свою работу с предложением удалить повреждённый файл, а после этого снова попытаться запустить CVSup. Если Вы последуете этому предложению, он завершит вашу коррекцию, используя методы аварийного перехода, упомянутые выше, и воссоздаст ваш checkout-файл для следующего раза.
Есть ещё одна вещь, которая может произойти, но это не очень существенно. CVSup удалит лишь файлы, которые указаны в его checkouts-файле. Таким образом, если Вы потеряете ваш checkouts-файл, а затем файл "foo" удаляется на стороне сервера, то после выполнения CVSup, ваш файл "foo" не будет удален.
Файл никогда не будет удалён из CVS-хранилища, но, в действительности, это несущественно. Чтобы быть уверенным в полной мере, Вы должны выполнить CVSup как можно раньше, т.е. как только Вы узнали о потере checkouts-файла, немедленно приступите к процедуре коррекции.
Если вы осторожны и если вы понимаете что происходит за сценой, вы можете сделать это. CVSup разрабатывался для локальных проверок в соответствии с RCS файлами, взятыми из основного хранилища. Поскольку CVSup понимает структуру RCS файлов, он может произвести новые исправленные издания с сервера, не мешая вашим собственным исправленным изданиям, которые Вы изменили у себя. К несчастью, определённые логические вопросы делают эту возможность неудобной, для того, чтобы использовать её в практических ситуациях.
Для сохранения локальных исправленных версий в вашей копии хранилища CVS, Вы должны:
Ниже мы расскажем как это можно сделать.
Просто удалите ключевое слово "delete" из вашего cvsupfile. Присутствие этого ключа даёт CVSup право удалять исправления из RCS файлов. Также этот ключ разрешает CVSup удалять целиком файлы RCS, при условии, что он создаст их заново. Если вы уберёте ключ "delete", вы предохранитесь от удаления CVSup'ом локально исправленных изданий, а также RCS файлов. Тем не менее, очень важно понимать последствия удаления ключевого слова "delete".
Сначала, положим, что один из множества RCS файлов был удалён из хранилища CVS на стороне главного сервера. Без ключа "delete" CVSup не сможет удалить соответствующий файл в вашей локальной копии. Таким образом Вы будете иметь некоторые файлы RCS в вашем хранилище, которых, в противном случае, там не было бы.
В идеальном мире, это не проблема. Потому что, в идеальном мире никто не удаляет RCS файл из CVS хранилища. Таким образом, такая ситуация не должна возникать никогда.
К несчастью, большинство администраторов управляют своим хранилищем не так идеально, как хотелось бы. Коммиттеры делают ошибки и устанавливают файлы в неправильно. Большинство администраторов вручную исправляют такие ошибки, перемещая файлы в хранилище, а некоторые ошибки продолжают жить. Другой пример, в любом большом хранилище, некоторые файлы в конечном счете становятся полностью устаревшими. В итоге, разработчики пожалуются на неиспользуемое дисковое пространство и бардак в хранилище, и администратор хранилища, в ответ на их запрос, удалит файлы.
Обычно, восстановленные RCS файлы не вызывают никаких проблем и их можно благополучно игнорировать. Это особенно верно если администратор хранилища основного сервера был осторожным, чтобы выделить "мёртвые" файлы на всех ветках с выполнением команды "cvs remove" на несколько недель раньше, чем полностью удалить нежелательные файлы RCS. Тем не менее, дополнительные файлы RCS могут вызвать проблемы в некоторых случаях, и Вы должны знать об этом.
Это трудно, поскольку CVS выбирает очередной номер версии сам. Один из путей - немного исправить CVS. Прежде, чем обсуждать это, создайте новую ветку, где вы будете держать ваши локальные изменения. Не пытайтесь проверить ваши локальные изменения в основной ветке или в ветке, которая существует в основном хранилище. Если вы так сделаете, то, скорее всего, рано или поздно, возникнут коллизии.
Если ваши локальные исправленные издания находятся на своей собственной ветке, то проблема сводится к гарантии, что ваша ветка имеет уникальный номер исправленного издания, который никогда не задублируется с номером в основном хранилище. Наилегчайший путь - модифицировать CVS. Версия CVS (в составе дистрибутива FreeBSD) включает такую модификацию. В этой версии, Вы можете влиять на номера исправленных изданий ответвлений, устанавливая внешнюю переменную CVS_LOCAL_BRANCH_NUM.
Эта переменная должна устанавливаться в целое, и CVS будет использовать её, как отправной пункт, выбирая номер для исправленного издания в новых ветках. По умолчанию, CVS распределяет отраслевые номера начинаемые с 1. Следовательно, много большее число, как например, 1000 - хороший выбор. Новые ветки получат меньшие номера, когда ваши собственные локальные ветки получат большие номера исправленного издания. Таким образом эти ветки не будут противоречить друг другу.
Используя этот метод, коммиттеры не должны устанавливать CVS_LOCAL_BRANCH_NUM создавая ветки в основном хранилище.
Если у Вас нет версии CVS, которая поддерживает CVS_LOCAL_BRANCH_NUM, то можно избежать конфликтов с помощью сотрудничества с основным сервером. Просто создайте ветку в основном хранилище, объявите что, она зарезервирована для локальных модификаций, и не используйте её в основном хранилище.
Создайте где-нибудь пустую директорию. Мы будем называть её 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, запускаем
cvsup как обычно. Самый простой способ:
cvsup supfile
но Вы, если хотите, можете добавить -g -L 2 для подавления GUI.
Если вы запустили CVSup клиента, собранного с GUI, нажмите кнопку start. Не-GUI клиент запустится автоматически. Индикатор диска включится на 50 ватт и жёсткий диск начнёт шуметь, говоря вам "Я на самом деле, абсолютно точно, реально занят." Когда шум прекратится, вы найдёте в директории dest свежие файлы. Появится директория sup в которой cvsup сделает записи состояния.
Надеюсь это сработает и вы сможете провести более тщательное испытание, чем это. При манипулировании исходными RCS файлами, вы можете добавлять дельты и/или таги, убеждаясь, что всё получается как надо в момент следующего "наката". Вы также можете попробовать удалить RCS файлы и добавить несколько новых. На стороне клиента вы можете добавлять tag= и/или date= директивы в supfile. Главное состоит в том, что если программное обеспечение работает на вашей платформе, это значит, что работа по настройке сервера выполнена. Практически вся функциональность базируется коде, независимом от операционной системы.
Одно предостережение: Выполнение "наката" на одной машине через localhost очень сильно нагружает систему, особенно дисковую подсистему и сетевой стек. Будут показаны все ошибки операционной системы, которые ранее были неизвестны. Если у вас возникли околосетевые проблемы, возможно вам поможет использование -P m в командной строке cvsup.
Файлы конфигурации сервера, используемые проектом FreeBSD доступны через CVSup с любого зеркала FreeBSD. Для того, чтобы сделать копию, зайдите в пустую директорию и создайте файл supfile, содержащий такой текст:
*default host=a.mirror.site compress
*default release=cvs tag=.
*default base=.
*default delete use-rel-suffix norsync
distrib
Замените a.mirror.site любым CVSup, указанным в Справочнике FreeBSD.
Запустите CVSup клиента, использующего этот supfile. Когда он завершит свою работу, Вы найдете файлы конфигурации
в поддиректории distrib/cvsup. Если Вы хотите использовать именно эти файлы конфигурации,
Вы должны использовать эту поддиректорию как вашу base директорию, подобно этому:
cvsupd -b distrib/cvsup ...
В реальной установке, Вы должны определить базовую директорию как полное составное имя.
Основная проблема в том, что CVSup написан на языке программирования NotC. Что такое NotC? Хорошо, для большинства людей, это действительно не имеет значения. Самое главное то, что NotC не C. Следовательно, нужна небольшая дополнительная работа, чтобы использовать это.
В случае CVSup, NotC это Modula-3. Modula-3 - эффективный язык программирования с отличной встроенной поддержкой таких важных характеристик как, например, сборка мусора и нити (threads). За более подробной информацией о Modula-3, обратитесь на Modula-3 Home Page.
К счастью, существуют порты Modula-3 для многих платформ. Если порт для вашей платформы уже есть, то тогда Вы уже прошли самый большой барьер в построении CVSup.
Вторая проблема, с которой встречаются многие люди, в том, что построение компилятора и runtime Modula-3 требует много виртуальной памяти. Вам нужно порядка 64 MB доступной виртуальной памяти. (Построение CVSup менее требовательно.) Вы также должны гарантировать, что ресурсов достаточно. Ими можно управлять с помощью команды "ulimit" в sh-подобных оболочках, или командой "limit" в csh.
Третье, по умолчанию у Вас должны быть установлены X11 в вашей системе, чтобы сформировать runtime Modula-3. Можно формировать Modula-3 без X11, и чтобы сделать так, Вы должны отредактировать файл m3/src/m3makefile и закомментировать пакеты, которые зависят от X11.
Нет, CVSup к настоящему времени не работает на платформах Windows. В своей работе CVSup опирается на многие характеристики, которые характерны для POSIX-подобных операционных систем.
Обычно, все ранее вышедшие версии CVSup могли работать друг с другом. Однако, это стало неприемлемо, всвязи с обнаружением несчастной ошибки s1g, которая присутствует во всех версиях CVsup до SNAP_16_1d. CVSup-клиенты, в которых содержится ошибка "s1g", создают огромную нагрузку на CVSup-серверы.
Для защиты серверов от этой проблемы, начиная с версии SNAP_16_1e была добавлена проверка. Теперь новые CVSup-серверы не разрешают воспользоваться сервисом, если CVSup-клиенты содержат ошибку "s1g". Когда такой клиент посылает запрос на сервер с версией SNAP_16_1e или выше, сервер немедленно разрывает соединение и сообщает клиенту о проблеме. В сообщении содержится информация о возможности получения новой версии CVSup.
CVSup-клиенты также нуждаются в защите серверов со старыми версиями, которые поставляют файлы с некорректными датами. Итак, дополнительная проверка была добавлена для клиентов с версии SNAP_16_1e. Если новый клиент соединится к CVSup-серверу, который содержит ошибку "s1g", клиент укажет на ошибку и немедленно завершит работу. В сообщении об ошибке содержится описание проблемы и просьба сообщить владельцу этого сайта, что программное обеспечение его CVSup-сервера устарело.
Нет. Хотя CVSup-клиент умеет пользоваться supfile'ами записанными для SUP, эти два пакета не совместимы.
К сожалению, CVSup не годится для решения этой задачи. CVSup был разработан исключительно для однонаправленного зеркалирования. Если Вы хотите использовать его в обеих направлениях, Вы можете столкнуться с различными проблемами. Например, если конфликтные изменения внесены в файл, как разрешить эту ситуацию? Возможно, существует какое-то разрешение этой проблемы, но Вы должны найти его самостоятельно.
Извините, но мне ничего неизвестно о подобных инструментах.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |