Gentoo.ru: Учебное пособие по CVS в Gentoo Linux


Gentoo.ru: Учебное пособие по CVS в Gentoo Linux
Новости ::
Магазин ::
Библиотека ::
Linuxbegin ::
Gentoo.ru ::
Redhat ::
Unix4all ::
HURD.RU ::
Форум
Русское сообщество Gentoo
Учебное пособие по CVS в Gentoo Linux
Версия: 1.1 от 17 Мая 2003
Описание:
Данное руководство познакомит читателей с CVS, системой используемой
людьми для совместной разработки программного обеспечения по всему
миру. Предназначенное для новичков, оно быстро ознакомит пользователей
и разработчиков с общими принципами CVS. Собираетесь ли вы
использовать CVS для получения (check out) последних версий
программного обеспечения, или же вы решили как профессиональный
разработчик ознакомиться с его возможностями, данное руководство для вас.
Над документом работали: Chief Architect: Daniel Robbins
( drobbins@gentoo.org )
Переводчик: Иван Зенков
( zenkov@gentoo.org )
Содержание:
1. Введение1.1. Построение документа1.2. Что такое CVS и для чего это нужно?1.3. Роль CVS1.4. Свежие исходники от разработчиков из CVS1.5. Есть ли у вас CVS?1.6. Сборка CVS из исходных файлов1.7. CVSROOT1.8. Локальный CVSROOT1.9. CVSROOT для защищённого удалённого сервера1.10. Удалённый rsh/ssh CVSROOT1.11. Ещё несколько вещей...1.12. Работа с CVS, часть 11.13. Работа с CVS, часть 21.14. Работа с CVS -- разъяснения1.15. Завершение загрузки1.16. Обновление исходников1.17. Следим за "cvs update", часть 11.18. Следим за "cvs update", часть 22. CVS для разработчиков2.1. Изменение файлов2.2. CVS объединяет все изменения2.3. Несовершенство объединения2.4. Отправка2.5. Что делает "commit"?2.6. Просмотр log файлов2.7. Опции "commit"2.8. Файл .cvsrc2.9. Файл .cvsrc -- дополнение2.10. Добавление файла в репозитарий2.11. Добавление директории в репозитарий2.12. Примечания к "cvs add"2.13. Знакомимся с "cvs update", часть 12.14. Знакомимся с "cvs update", часть 22.15. Знакомимся с "cvs update", часть 32.16. Разрешение внутренних конфликтов2.17. Пример конфликта2.18. Пример конфликта, продолжение2.19. Разрешение конфликта, часть 12.20. Разрешение конфликта, часть 22.21. Советы в разрешении конфликтов2.22. Удаление файла2.23. Удаление файла, продолжение2.24. Удаление директории2.25. Удаление директории, продолжение2.26. Завершение!
1. Введение
1.1. Построение документа
Это руководство состоит из двух частей. Первая, объяснит обычным
пользователям как использовать CVS. Например, как получать и
обновлять исходные файлы. Вторая, предназначенная для разработчиков,
помимо всего прочего расскажет как редактировать, удалять и добавлять
файлы в CVS. Если вы никогда раньше не использовали CVS,
рекомендуется начать с первой части, а далее уже дочитать и
вторую. Если же у вас уже есть некоторый опыт использования CVS, но вы
собираетесь использовать CVS на уровне разработчика всё, что
необходимо можно найти во второй части, хотя первая может пригодиться
в качестве вступления.
1.2. Что такое CVS и для чего это нужно?
CVS это клиент-серверная система позволяющая разработчику хранить свои
проекты в одном единственном месте, называемом репозитарий.
Разработчик может изменять содержимое репозитария, используя CVS
клиент. В свою очередь CVS отслеживает каждое изменение, сделанное над
каждым файлом, создавая законченную хронологию развития
проекта. Разработчик может просмотреть лог файл изменений, запросить
более старую версию любого исходного файла, и при необходимости
использовать дополнительные возможности CVS.
1.3. Роль CVS
Множество open source проектов имеют собственный CVS репозитарий,
используемый разработчиками как архив всей их работы. Рассеяные по
всему миру, они могут хоть по несколько раз на дню изменять исходные
файлы в CVS. То есть CVS это механизм необходимый для объединения
проекта в связанное целое, для его централизации. CVS как бы
"организационное связывающие звено", позволяющие разработчикам
совершенствовать код не наступая друг другу на ноги, теряя важные
данные и пропуская критические обновления к специфическим исходным
файлам.
1.4. Свежие исходники от разработчиков из CVS
Когда разработчики готовы, текущая работа на CVS упаковывается ими в
.tar.gz файл и выпускается как новая официальная версия
программы. Однако, из-за ряда различных причин, официальная последняя
версия не всегда достаточно "последняя". В первой части данного
руководства я расскажу как использовать CVS для приобретения самых
последних версий исходных файлов для вашего личного пользования.
1.5. Есть ли у вас CVS?
Перед использованием CVS, как ни странно, его необходимо
установить. Самый простой метод проверки его установки, это запуск
программы, командой:
Листинг
1.1
# cvs
Если команда найдена, тогда он у вас установлен. В противном же
случае вам понадобиться установить его из бинарного пакета для вашего
дистрибутива или собрать прямо из исходных файлов. Сборка CVS из
исходных файлов на самом деле достаточно проста, об этом я расскажу
чуть ниже.
1.6. Сборка CVS из исходных файлов
Собрать CVS очень просто. Для начала загрузим cvs-1.11.tar.gz архив с
ftp://ftp.cvshome.org/pub/cvs-1.11/cvs-1.11.tar.gz (если
здесь, доступна более
новая версия, то лучше её и загрузить). После чего выполним следующие
шаги (для компактности вывод команд был опущен):
Листинг
1.2
# tar xzvf cvs-1.11.tar.gz
# cd cvs-1.11
# ./configure
# make
# make install
Теперь всё готово и можно приступать к работе.
1.7. CVSROOT
Перед началом, необходимо запомнить несколько фундаментальных основ
CVS. Перове - для соединения с CVS архивом необходимо знать путь,
называемый "CVSROOT". Значение CVSROOT подобно URL сообщает программе
где находится удаленный архив и каким способом мы бы хотели с ним
соединиться. Любопытно то, что CVS имеет несколько форматов CVSROOT в
зависимости от локального или удаленного местонахождения репозитария, а
также метода используемого вами для соединения с ним. Вот примеры
CVSROOT, вместе с разъяснениями.
1.8. Локальный CVSROOT
Листинг
1.3
CVSROOT=/home/cvsroot
Это пример локального CVSROOT. Используя CVSROOT вроде этого, вы
подключитесь к локальному репозитарию находящемуся в /home/cvsroot
или возможно смонтированному через NFS к /home/cvsroot.
1.9. CVSROOT для защищённого удалённого сервера
Листинг
1.4
CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot
Это пример CVSROOT для удалённого репозитария с хостом foo.bar.com и
находящегося в директории /home/cvsroot на той машине. Часть
":pserver:" сообщает клиенту, что для подключения к репозитарию
следует использовать защищённый серверный протокол (password server
protocol), протокол встроенный в CVS. Обычно публичные CVS
репозитарии, дают ограниченный доступ, анонимным (anonymous)
пользователям используя защищённый серверный протокол.
1.10. Удалённый rsh/ssh CVSROOT
Листинг
1.5
CVSROOT=drobbins@foo.bar.com:/data/cvs
Данный пример CVSROOT, использующий RSH или SSH протокол, позволяет
пользователю с учётной записью drobbins получить доступ к удалённому
репозитарию на foo.bar.com. В случае если системная переменная CVS_RSH
содержит значение "ssh", для соединения cvs клиентом будет
использоваться ssh, иначе всё тот же rsh. Ssh метод популярнее введу
своей безопастности. Однако ни тот ни другой, не подойдут для
анонимного пользователя желающего получить исходные файлы, поскольку
необходимо иметь учётную запись на сервере foo.bar.com.
1.11. Ещё несколько вещей...
В дополнение к CVSROOT, вам так же понадобится название модуля
(коллекции исходных файлов), что вы хотели бы получить. А так же
анонимный пароль, необходимый для защищенного CVS сервера. В отличии от
анонимного ftp, здесь нет "стандартного" формата для анонимных
паролей, вам нужно будет получить пароль с сайта разработчиков или у
разработчиков лично. Теперь когда у вас всё есть, можно приступать к
работе.
1.12. Работа с CVS, часть 1
Получение исходных файлов, состоит из двух стадий. Первое, мы должны
подключиться к защищённому серверу. После чего, командой
checkout получить собственно сами исходники. На нашем примере,
следующими командами, мы попытаемся получить последние исходные файлы
Samba, популярного проекта UNIX/Windows интеграции.
Листинг
1.6
# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot
Эта первая команда, задаёт системную переменную CVSROOT. Если вы не
зададите эту переменную следующие две команды потребуют добавления
ключа -d :pserver:cvs@pserver.samba.org:/cvsroot после команды
cvs. Экспортирование переменной CVSROOT, экономит количество
вводимых знаков.
1.13. Работа с CVS, часть 2
Вот команды, необходимые для получения текущей версии исходников. Вы
можете просмотреть объяснение команд чуть ниже, а затем опять вернуться
к этой части.
Листинг
1.7
# cvs login
(Logging in to cvs@pserver.samba.org)
CVS password: (Здесь введите пароль)
# cvs -z5 co samba
U samba/COPYING
U samba/Manifest
U samba/README
U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
(Это только отрывок, вывода cvs co)
1.14. Работа с CVS -- разъяснения
Первая команда cvs регистрирует нас в pserver, вторая сообщает нашему
CVS клиенту забрать ("co") модуль samba, используя gzip с уровнем
сжатия 5 ("-z5"), для ускорения передачи файлов по медленному
соединению.
Для каждого нового файла, созданного локально, cvs выводит идентификатор
"U [path]" означающий обновление данного файла на диске.
1.15. Завершение загрузки
Сразу после выполнения загрузки, в текущей рабочей директории вы
увидите каталог "samba" содержащий все последние исходные
файлы. Возможно вы также заметите, что все директории имеют внутри
себя, каталог "CVS". CVS сохраняет некоторую информацию внутри этих
каталогов, они могут безопасно игнорироваться. С этого момента, мы
можем не волноваться об установленной системной переменной CVSROOT, и
нет нужды каждый раз задавать её, поскольку всё кэшировано во
внутренних, дополнительных каталогах "CVS". Запомните -- CVSROOT вам
требуется задать только для входа на сервер и получения необходимых
файлов.
1.16. Обновление исходников
Хорошо, теперь у нас есть самые свежие исходники! Их можно
скомпилировать и установить программу, можно просмотреть, можно
делать с ними всё, что захотите.
Время от времени, вам возможно понадобиться обновить исходники, в
соответствии с текущей версией на CVS. Для этого, вам не понадобиться
подключаться к pserver; вся необходимая информация кэширована внутри
тех самых каталогов "CVS". Перовое, войдите в установочную директорию
(в нашем случае "samba") и напечатайте:
Листинг
1.8
# cvs update -dP
1.17. Следим за "cvs update", часть 1
Если есть любые новые файлы, cvs выведет строку "U [path]" для
каждого обновлённого файла. В случае же когда вы скомпилировали
исходные файлы, вы возможно увидите множество строк "? [path]",
сообщающих, что эти объектные файлы не из удалённого репозитария.
1.18. Следим за "cvs update", часть 2
Также обратите внимания на две опции командной строки, используемых
нами для "cvs update". "-d" сообщает cvs создавать любые новые
каталоги, которые возможно были добавлены в репозитарий (по умолчанию
этого не происходит), и "-P" сообщающий cvs удалять пустые директории
из локальной копии с исходниками. Использование "-P" хорошая идея,
поскольку cvs имеет тенденцию, спустя некоторое время, скапливать
множество пустых (когда-то используемых, но уже давно заброшенных)
директорий.
Это всё, что вам требуется знать для простого получения свежих
исходников. Теперь же возьмёмся за CVS с позиции разработчика.
2. CVS для разработчиков
2.1. Изменение файлов
Как разработчику, вам потребуется изменять файлы на CVS. Для
этого, просто сделайте необходимые изменения в локальной копии
репозитария. Изменения сделанные вами не будут приняты в удалённом
репозитарии, до тех пор пока вы их не отправите (commit).
Проверив свои изменения, и убедившись в их пригодности, для принятия
изменений в репозитарии необходимо выполнить два шага. Первое,
обновите ваши исходные файлы, набрав в основной директории,
команду:
Листинг
2.1
# cvs update -dP
2.2. CVS объединяет все изменения
Как мы уже видели выше, "cvs update" поддерживает ваши исходники на
современном уровне до текущей версии в репозитарии. Но что же
происходит со сделанными вами изменениями? Не волнуйтесь - они не были потеряны.
Если другой разработчик сделает изменения в файле, которого вы не
коснулись, ваш локальный файл будет обновлён в соответствии с версией
в репозитарии.
А если вы измените 1-10 строк в локальном файле, а другой
разработчик, сотрёт 40-50 и добавит 12 в конце, изменив 30-40 строк и
отправив (committed) свои изменения в репозитарии раньше вас, cvs
разумно объединит все изменения в вашей локальной копии, при этом
сохранив и ваше редактирование. Что позволяет двум и более
разработчикам одновременно работать над разными частями одного и того
же файла.
2.3. Несовершенство объединения
Однако, если два или более, разработчиков изменили одну и туже
область, одного и того же файла, всё становится немного сложней.
Если это произойдёт, cvs сообщит вам о случившемся конфликте. Работа
не будет потеряна, но потребуется немного человеческого вмешательства,
дабы объяснить cvs как лучше всего провести объединение конфликтующих
изменений.
2.4. Отправка
Немного позже мы ещё посмотрим как могут быть решены конфликты, а пока
предположим, что напечатав "cvs update -dP" всё прошло
успешно. Конфликтов нет, ваши локальные исходники самые свежие и вы
готовы отправить ваши изменения в репозитарий набрав:
Листинг
2.2
# cvs commit
2.5. Что делает "commit"?
"cvs commit" не только принимает ваши изменения в
репозитарий. Перед отправкой ваших изменений в удалённый репозитарий,
cvs запустит заданный по умолчанию редактор, где вы можете
прокомментировать сделанные вами изменения. Как только вы введёте
комментарии, сохраните файл и выйдете из редактора, ваши изменения (и
комментарии) будут отравлены в удалённый репозитарий и станут доступны
другим разработчикам из вашей команды.
2.6. Просмотр log файлов
Просмотреть полную историю отдельного файла,
включая все комментарии разработчиков (и вас тоже), возможно сделанные
ими при отправки файлов довольно просто. Для этого нужно набрать:
Листинг
2.3
# cvs log myfile.c
Команда "cvs log" рекурсивна, то есть если вы хотите просмотреть
полный log дерева каталогов, просто зайдите в директорию и
напечатайте:
Листинг
2.4
# cvs log | less
2.7. Опции "commit"
Возможно вы хотели бы выбрать другой редактор, чем тот, что
запускается по умолчанию при выполнении "cvs commit". Если это так,
сделайте значением системной переменной EDITOR название редактора
который вы бы хотели использовать. Также было бы хорошей идей
поместить это определение в ~/.bashrc:
Листинг
2.5
export EDITOR=jpico
Альтернативно, можно указать log сообщение в качестве опции командной
строки (в данном случае редактор запускаться не будет).
Листинг
2.6
# cvs commit -m 'I fixed a few silly bugs in portage.py'
2.8. Файл .cvsrc
Перед тем как продолжить изучение прочих cvs команд, я советую создать
~/.cvsrc файл. Создавая .cvsrc в вашем домашнем каталоге, вы можете
задать по умолчанию, опции которые не хотели бы каждый раз заново
набирать. Вот рекомендуемый .cvsrc файл:
Листинг
2.7
cvs -q
diff -u -b -B
checkout -P
update -d -P
2.9. Файл .cvsrc -- дополнение
В дополнение к установке полезных опций для команд cvs, первая строка
.cvsrc переводит cvs в тихий режим (quiet mode), который отлично
подходит для "cvs update", делая вывод на терминал более читабельным.
Теперь как только .cvsrc будет на месте вы сможете использовать "cvs
update" взамен "cvs update -dP".
2.10. Добавление файла в репозитарий
Добавить файл в CVS, очень просто. Для начала, создайте в вашем
любимом текстовом редакторе, файл. Затем напечатайте:
Листинг
2.8
# cvs add myfile.c
cvs server: use 'cvs commit' to add this file permanently
Как сказано в сообщении, cvs добавит данный файл сразу после того как
вы выполните "cvs commit", до тех же пор он не будет доступен другим
разработчикам.
2.11. Добавление директории в репозитарий
Процесс добавления каталога, схож с добавлением файла:
Листинг
2.9
# mkdir foo
# cvs add foo
Directory /home/cvsroot/mycode/foo added to the repository
В отличии от добавления файла, добавленный каталог немедленно
появляется в репозитарии; "cvs commit" не требуется. Как только вы
добавите ваш локальный каталог к cvs, обратите внимание, внутри будет
создана директория "CVS" -- этакий контейнер для учётной
информации. Таким образом, вы могли бы легко всё сказать, если отдельный
каталог был добавлен в cvs, заглянув внутрь директории "CVS".
2.12. Примечания к "cvs add"
Эх, ну и конечно перед добавлением файла или директории в репозитарий, вы
должны удостовериться в том, что их родительский каталог уже был
добавлен в CVS. В противном случае вы получите подобную ошибку:
Листинг
2.10
# cvs add myfile.c
cvs add: cannot open CVS/Entries for reading: No such file or directory
cvs [add aborted]: no repository
2.13. Знакомимся с "cvs update", часть 1
Перед тем как мы рассмотрим проблему разрешения конфликтов, давайте
взглянем подробней на вывод команды "cvs update". В случае когда
созданный вами файл ~/.cvsrc содержит строку "cvs -q", вывод "cvs
update" будет намного читабельной. "cvs update" информирует вас о
происходящем выводя одну букву, пробел и имя файла; как например так:
Листинг
2.11
# cvs update -dP
? distfiles
? packages
? profiles
2.14. Знакомимся с "cvs update", часть 2
Используя символ "?" "cvs update" сообщает вам о том, что ничего не
знает о файлах найденных в вашей локальной копии репозитария. Они не
официальная часть архива, не помеченные для добавления. Вот список
всех остальных одно-буквенных сообщений используемых в CVS:
Листинг
2.12
U [path]
Используется в случае создания нового файла в локальной копии
репозитария, или обновления не тронутого вами файла.
Листинг
2.13
A [path]
Этот файл уже помечен для добавления, и будет официально добавлен в
репозитарий после выполнения "cvs commit".
2.15. Знакомимся с "cvs update", часть 3
Листинг
2.14
R [path]
Подобно "A", "R" сообщает вам о том, что файл был помечен для удаления
и после выполнения "cvs commit" будет полностью удалён.
Листинг
2.15
M [path]
Это означает, что данный файл был изменён вами; также возможно что
новые изменения из репозитария были успешно объединены внутри него.
Листинг
2.16
C [path]
Символ "C" сообщает, о конфликтах с данным файлом, требующих ручного
вмешательства перед выполнением "cvs commit".
2.16. Разрешение внутренних конфликтов
Теперь давайте взглянем на проблему разрешения конфликтов. Я участвую
в проекте Gentoo Linux, и у нас есть собственный cvs сервер,
cvs.gentoo.org. Мы, разработчики, проводим большенство нашего времени
"хакая" исходники внутри модуля "gentoo-x86". В каждом каталоге есть файл
"ChangeLog" который содержит (вы возможно уже сами догадались)
описание основных изменений сделанных над файлами в репозитарии.
2.17. Пример конфликта
Поскольку этот файл обновляется почти каждый раз когда
разработчики производят значительные изменения в CVS, это первичный
источник конфликтов -- вот пример конфликта. Предположим я добавил
следующие строки в начало файла "ChangeLog":
Листинг
2.17
date 25 Feb 2001
Это то, что я добавил
Однако предположим, что перед тем как я добавил эти три строки, другой
разработчик уже добавил несколько строк в начало файла "ChangeLog" и
отправил свои изменения:
Листинг
2.18
date 25 Feb 2001
Это фрагмент добавленный другим разработчиком
2.18. Пример конфликта, продолжение
Теперь когда я запускаю "cvs update -dP" (это необходимо делать всегда,
перед выполнением "commit"), cvs не может добавить его изменения в мою
локальную копию "ChangeLog" потому, что мы добавляем строки в одну и
туже часть файла -- как cvs определит какую версию использовать? Так
я получаю следующую ошибку от CVS:
Листинг
2.19
RCS file: /home/cvsroot/gentoo-x86/ChangeLog,v
retrieving revision 1.362
retrieving revision 1.363
Merging differences between 1.362 and 1.363 into ChangeLog
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in ChangeLog
C ChangeLog
2.19. Разрешение конфликта, часть 1
Ох, ну и конфликт! К счастью его несложно разрешить. Если я запущу
мой любимый текстовый редактор, вверху файла "ChangeLog" я увижу
следующий текст:
Листинг
2.20
<<<<<<< ChangeLog
date 25 Feb 2001
Это то, что я добавил
=======
date 25 Feb 2001
Это фрагмент добавленный другим разработчиком
>>>>>>> 1.363
2.20. Разрешение конфликта, часть 2
Вместо выбора одной или другой версии, cvs добавил обе к файлу
"ChangeLog", разделив их специальным разделителем, чтобы ясно отметить
рассматриваемый конфликт. Теперь моя очередь заменить эту область на
текст который должен находиться в "ChangeLog"; в данном случае
нужна не одна или другая версия, а комбинация обоих:
Листинг
2.21
date 25 Feb 2001
Это то, что я добавил
Это фрагмент добавленный другим разработчиком
Теперь когда я заменил противоречивую область файла соответствующим
текстом (и удалил разделитель "=======", вместе с прочими маркерами),
я могу спокойно и беспроблемно отправить свои изменения в cvs.
2.21. Советы в разрешении конфликтов
Всякий раз, когда вы редактируете конфликтный файл, удостоверьтесь в
том, что вы просматриваете наиболее полную версию файла; если вы
забудете разрешить специфический конфликт, cvs не позволит активировать
"commit" пока конфликт не будет разрешён! Также очень важно удалить
специальные маркеры добавляемые cvs в конфликтный файл. Другой совет
-- если при разрешении конфликта вы совершите ошибку и случайно
("Ох!") сохраните свои изменения, первоначальную копию вашей версии
можно найти в файле ".#filename.version".
2.22. Удаление файла
Теперь настало время изучить последнюю возможность -- удаление файлов
из репозитария. Процесс удаления файла состоит из двух шагов.
Сначала, удаляем файл из локальной копии репозитария, а затем выполняем
соответствующую команду "cvs remove":
Листинг
2.22
# rm myoldfile.c
# cvs remove myoldfile.c
2.23. Удаление файла, продолжение
Помеченный файл удалится из репозитария в следующий раз, как только вы
выполните "commit". После выполнения "commit", файл будет официально
удалён из текущей версии репозитария. Однако cvs не выбросит этот
файл, и на всякий случай сохранит законченный отчёт о его содержании и
хронологии, который возможно понадобится в будущем. Это только один
из многих способов которыми cvs защищает ваш исходный код.
"cvs remove" рекурсивна, это означает, что вы можете удалять сразу
связку файлов, запустив команду "cvs remove" без аргументов из
родительской директории. Проделав это, мы получим файлы помеченные к
удалению до следующего запуска "commit".
2.24. Удаление директории
Если вы хотите удалить полный каталог, я рекомендую проделать следующие.
Сначала, физически удаляем все файлы в директории, а затем "cvs remove":
Листинг
2.23
# rm *.c
# cvs remove
2.25. Удаление директории, продолжение
Теперь выполним "commit":
Листинг
2.24
# cvs commit
Здесь присутствует некоторая уловка. Далее выполните следующие шаги,
чтобы просто удалить каталог:
Листинг
2.25
# cd ..
# cvs remove mydir
# rm -rf mydir
Обратите внимание, что удаление директории не требует ещё одного
запуска "commit" -- каталоги удаляются и добавляются из репозитария в реальном времени.
2.26. Завершение!
Ваше знакомство с CVS завершено -- я надеюсь, что данное пособие было
полезно. CVS содержит гораздо больше чем я мог охватить в этом
вводном обучающем документе, но к счастью есть целая связка ресурсов
которые можно использовать для дополнительной развёртки ваших знаний:
http://www.cvshome.org это дом разработки CVS, и целый набор документации включая
официальную online документацию по CVS.
Сайт CVS Version Control for Web Site Projects
хорошая информация об использовании CVS в разработки вэб проектов.
Карл Фогел (Karl Fogel) написал книгу
Open Source Development with CVS.
Несколько глав бесплатно доступны на сайте.
cvsweb
это действительно замечательный CGI скрипт, создающий вэб интерфейс
для вашего CVS репозитария; превосходно для просмотра.
CVS Bubbles
имеет список хороших ресурсов включая CVS FAQ-o-matic.
Примечание:
Данное руководство впервые появилось на IBM developerWorks Linux Zone, под названием CVS for the developer or amateur (CVS для любителя и разработчика). Эта статья принадлежит Tenco Media Corporation.
| 2 | Amway
Используются технологии uCoz