Библиотека программиста

Все, что необходимо начинающему и опытному программисту

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

свежие резервные копии репозитория при выполнении описанных операций.

Изменение структуры проекта
Изменение структуры проекта, включающее перемещение файлов или каталогов внутри репозитория (с возможным изменением имен), позволяет сохранить историю изменения файлов. Стандартный способ переименования файла при использовании CVS состоит в следующем: переименовать файл в рабочем каталоге, выполнить cvs remove для предыдущего имени файла, а затем выполнить cvs add для нового имени файла. В результате происходит отрыв файла под новым именем от старой истории версий, поэтому иногда более предпочтительно произвести переименование напрямую в репозито-рий. Следует отметить, что опасно производить подобную операцию, если существует вероятность того, что разработчики имеют извлеченные копии
файлов в рабочих каталогах, поскольку информация в рабочих каталогах
будет относиться к файлу, который больше не существует в репозиторий. Групповое импортирование
При импортировании целого проекта все файлы проекта добавляются в ре-позиторий. Но если некоторые из этих файлов не должны добавляться в репозиторий, то их можно удалить. Обычно это делается командой cvs remove, но при этом копии удаленных файлов навечно останутся в репозиторий и будут храниться в каталоге Attic. Чтобы избежать этого, можно удалить файлы прямо из репозитория непосредственно перед началом взаимодействия с репозиторием в частных рабочих каталогах.
Импортирование
При наличии существующей базы кода у вас может возникнуть желание импортировать ее в CVS способом, позволяющим сохранить большую часть информации об истории. В этом разделе приведены инструкции по импортированию в CVS проектов, которые представляют собой моментальные копии кода, или проектов других систем управления версиями. Все способы, кроме прямого импортирования моментальной копии кода, основаны на преобразовании в файлы RCS с последующей заменой файлов RCS в соответствующих точках репозитория CVS.
Импортирование моментальных копий кода
Если вы поддерживали историю проекта путем периодического создания моментальных копий кода, можно импортировать первую из таких копий, пометить ее датой или номером версии, а затем произвести последовательное наложение обновлений файлов из более поздних архивов. Каждый набор может затем помещаться в репозиторий и получать идентификатор с целью создания репозитория с сохранением предшествовавшей импортированию истории проекта.
Для примера сначала распакуем дистрибутивы (предполагается, что они будут распакованы в каталоги, имена которых также содержат номера версий):
user@localhost$ tar xvzf foo-1,O.tar.gz useriaiocalhostS tar xvzf foo-1. Ltar.gz useriaiocalhostS tar xvzf foo-2.0.tar.gz
Затем сделаем копию первой версии, импортируем ее в репозиторий CVS, извлечем ее с целью создания песочницы (поскольку само по себе импортирование не копирует исходные тексты напрямую в рабочий каталог) и выполним cvs tag, чтобы присвоить версии символьное имя (метку), отражающую версию проекта:
userMocalhostS mkdir foo useraiocalhost$ cp -R -p foo-1.0/* foo
userffllocalhostS cd foo
useraiocalhost$ cvs import -m • Imported version 1.0' foo vendor start
user@iocalhost$ cd ..
useriaiocalhostS mv foo foo.bak
useriaiocalhostS cvs checkout foo
useriaiocalhostS cd foo
useriaiocalhostS cvs tag foo-l_0
use^aiocalhostS cd ..
Теперь запишем изменения между версиями 1.0 и 1.1 в рабочий каталог, поместим изменения в репозиторий, а также создадим метку:
usertaiocalhostS diff -Naur foo-1.0 foo-1.1 | (cd foo; patch -Np1) user@localhost$ cd foo
user@localhost$ cvs commit -m ¦ Imported version 1.Г usercaiocalhostS cvs tag foo-l_l
user@localhost$ cd ..
Затем запишем изменения между версиями 1.1 и 2.0 в рабочий каталог, поместим изменения в репозиторий, а также создадим метку:
usenaiocalhost$ cliff -Naur foo-1.1 foo-2.0 I (cd foo; patch -Npl)
usena>localhost$ cd foo
usenaiocalhost$ cvs commit -m 'Imported version 2.0'
user@localhost$ cvs tag foo-2_0
Теперь можно воспользоваться командой log для просмотра истории файлов, более старых версий файлов, и продолжить разработку с контролем версий.
Импортирование из RCS
Если вы переносите проект из RCS в CVS, следование приведенным ниже инструкциям поможет вам создать рабочий репозиторий CVS. Описанные операции включают внесение изменений непосредственно в репозиторий, поэтому должны выполняться с должной осторожностью.
Прежде чем начать, убедитесь, что никакие импортируемые в CVS файлы не заблокированы RCS. Создайте новый репозиторий CVS и модуль (либо новый модуль в существующем репозиторий). Затем создайте в репозиторий CVS набор каталогов, который отражает структуру каталогов импортируемого проекта. И, наконец, скопируйте все файлы версий (они имеют расширение ,v) проекта (которые могут быть в подкаталогах RCS) в соответствующие каталоги в репозиторий (без подкаталогов RCS).
Например, сначала скопируем каталог, который управляется RCS, создадим пустой каталог для новой структуры CVS, импортируем каталог, а затем извлечем файлы в рабочий каталог:
user@localhost$ mv foo foo-rcs user@localhost$ mkdir foo user@localhost$ cd foo
user@localhost$ cvs import -m 'New empty project' foo vendor start usens>localhost$ col .. user@localhost$ mv foo foo.bak user@localhost$ cvs checkout foo
Затем создадим каталоги и добавим их в репозиторий, чтобы воспроизвести структуру проекта RCS:
user@localhost$ cd foo usenaiocalhost$ mkdir dir user@localhost$ cvs add dir
user§localhost$ cd ..
Теперь скопируем файлы версий (,v) проекта RCS в репозиторий проекта CVS:
usenaiocalhostS cp -p foo-rcs/*,v $CVSROOT/foo usens>localhost$ cp -p foo-rcs/dir/*,v $CVSR00T/foo/dir
И, наконец, выполним в рабочем каталоге команду cvs update, чтобы получить наиболее свежие версии всех файлов:
usenaiocalhost$ cd foo user§localhost$ cvs upd
Импортирование из SCCS
Для того чтобы импортировать проект из SCCS, воспользуйтесь сценарием
sccs2rcs, который расположен в каталоге contrib дистрибутива CVS. Сценарий преобразует файлы в формат RCS, после чего останется выполнить описанную выше процедуру импортирования RCS. Чтобы воспользоваться этим способом, необходимо иметь установленные системы CVS и SCCS. Дополнительная информация находится в комментариях к сценарию.
Импортирование из PVCS
Для того чтобы импортировать проект из PVCS, воспользуйтесь сценарием pvcsJo_rcs, который расположен в каталоге contrib дистрибутива CVS. Сценарий преобразует файлы в формат RCS, после чего останется только выполнить описанную выше процедуру импортирования RCS. Чтобы воспользоваться этим способом, необходимо иметь установленные системы CVS и
PVCS. Дополнительная информация находится в комментариях к сценарию.

Использование промежуточного разделяемого рабочего каталога
Иногда случается так, что проект оказывается нежелательным образом привязанным к окружению разработки, особенно если изначально нет никаких
требований к возможной смене окружения. Проект, который развивался без контроля версий, мог вообще разрабатываться в среде, которая будет являться основной для применения результатов. Несмотря на то что такая практика не рекомендуется, ситуации, подобные вышеописанным, имеют место в реальных проектах. CVS может успешно использоваться для исправления таких ситуаций, с самого начала позволяя координировать возможный впоследствии перенос проекта между средами.
Стандартным режимом работы для CVS является использование многочисленных, независимых рабочих каталогов, связанных с одним централизованным, разделяемым хранилищем данных. Код, выполняемый в таком окружении, обязательно (по крайней мере, частично) является независимым
от среды. Таким образом, использование CVS с самого начала разработки
проекта обеспечивает определенную гибкость.
Однако если проект уже в самом разгаре, может быть использовано промежуточное решение. Например, область разработки может быть преобразована в единый, разделяемый рабочий каталог посредством импортирования
кода в CVS и последующего извлечения его из репозитория:
user@localhost$ cd /usr/local/bar
user@localhost$ cvs import bar vendor start
useriaiocalhostS cd .. useriaiocalhostS mv bar bar.bak useriaiocalhostS cvs checkout bar
Высока вероятность того, что такой подход окажется слишком агрессивным и в репозиторий попадет большее число файлов, чем необходимо. В таком случае можно вернуться и удалить из репозитория файлы, которым там не место, либо выполнять команду cvs remove по мере обнаружения ненужных
файлов.
Кроме того, в рабочем каталоге почти наверняка окажутся двоичные файлы, которые были импортированы как текстовые. Если вы видите двоичный файл, который должен храниться в репозиторий, необходимо выполнить команду cvs admin -kb file, а затем сделать новую копию файла из резервных копий проекта. После этого команда cvs commit file поместит исправленный
файл обратно в репозиторий.
Систему контроля версий лучше вводить в действие в самом начале проекта, до того как станет необходимой оптимизация гибкости, поскольку нежелательные изменения могут быть легко найдены и обращены.
Путь к репозиторию (см. далее раздел «Путь к репозиторию») указывается в параметре -d или с помощью переменной окружения $CVSROOT. Путь хранится в файлах CVS/root рабочих каталогов. При использовании сервера паролей (pserver), запоминается идентификатор пользователя (ГО), извлекающего файлы в рабочий каталог. Если с определенным рабочим каталогом работают несколько человек, им придется делить учетную запись для доступа к CVS.
Это можно реализовать путем создания записи для нейтрального пользователя с паролем, известным всем, кто имеет доступ к репозиторию CVS. Тогда каждый сможет выполнить команду cvs login с одним и тем же пользовательским идентификатором и паролем для того, чтобы получить доступ к ре-позиторию. Когда вы закончите работу с разделяемым рабочим каталогом,
такой не совсем удобный способ станет ненужным. Однако в процессе использования разделяемого рабочего каталога необходимо позаботиться о
том, чтобы разработчики указывали свои действительные пользовательские
идентификаторы в записях журнала изменений, поскольку в противном
случае все изменения будут приписаны «коллективному» пользователю.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru