LXF70:Subversion2
|
|
|
Содержание |
Subversion. Используем клиент
ЧАСТЬ 2: У вас уже есть репозитарий Subversion – теперь попробуем работу с Subversion в качестве клиента. Грэм Моррисон расскажет, что надо делать.
Надеемся, после введения в работу с Subversion, вы вполне можете избавить себя от старых CVS-серверов, которые, должно быть, пылятся в какой-нибудь темной комнате. Мы показали, что перейти на новое поколение программного обеспечения для контроля версий достаточно легко (а почему бы и нет, когда уже не существует свободно распространяемой версии BitKeeper). Тем не менее, настройка и администрирование сервера Subversion потребуют определенных навыков, которые должны пригодится каждому менеджеру проектов. В этом номере мы предоставим наиболее распространенное решение для большинства разработчиков – использование Subversion в качестве клиента.
Итак, клиент – это та часть, которая получает доступ к серверу и разбирается со всеми сложными деталями, например, решает, какую версию кода выбрать, и как лучше будет исправить проблемы с конфликтами версий. Это некий интерфейс между локальной копией проекта, копиями, которые также находятся у других разработчиков, и главной версией на сервере Subversion.
Использование клиента Subversion – это также и заманчивый способ скачать последние исправления в каком-нибудь программном продукте, например, обновления безопасности и новые возможности, которые только-только появились в основной ветке. Вам придется быть внимательным, так как все, что доступно в репозитарии Subversion, постоянно находится «в движении». Каждый день можно наблюдать некоторые изменения, порой достаточно значительные. Это даже похоже на чтение книги, которую еще не закончил писать ее автор.
В этом обзоре мы сконцентрируемся на использовании клиента на этапе кодирования проекта в цикле разработке ПО, где Subversion, несомненно, примененяется наиболее часто. Руководство будет содержать те же примеры, что и в предыдущем случае. На страницах обзора вы сможете узнать о том, как загружать, изменять, добавлять файлы, а также анализировать проделанную работу, что, будет вполне достаточно для того, чтобы сделать свой личный вклад в ваш любимый проект.
Часть 1 - загрузка проекта с сервера Subversion
Первое, что надо сделать, если вы работаете над проектом, который находится под управлением сервера Subversion, - загрузить вашу собственную рабочую копию исходных текстов. Эту тему мы уже обсуждали в прошлый раз, и все, что вам потребуется вспомнить - это то, что мы использовали команду svn co:
$ svn co file:///usr/share/subres. A subres/helloworld.cpp A subres/Makefile Checkedout revision 1
Путь к хранилищу исходных текстов обычно начинается с ‘svn://’, что говорит о внешнем соединении с репозитарием, расположенным где-то в недрах сети Интернет. Но вы также можете указать локальный репозитарий (используя ‘file://’), который мы вместе создали в прошлый раз. Работа на локальном уровне значительно упрощает процесс экспериментирования, особенно в плане обновления данных. В случае работы с удаленными репозитариями получить права на запись сложней, по вполне понятным причинам. Так что ради того, чтобы поэкспериментировать, стоит создать и настроить собственное локальное хранилище исходных текстов абстрактного проекта.
Если у вас, как вы думаете, осталась работающая копия репозитария Subversion с прошлого раза, вы можете запросто проверить это при помощи команды svn info:
$ cd subres; svn info Path: . URL: file:///usr/share/subres Repository UU ID: 6319a556-cbf4-0310-b561-de3fb53aee82 Revision: 1 Node Kind: directory Schedule: normal Last Changed Author: graham Last Changed Rev: 1 Last Changed Date: 2005-04-15 16:33:44 +0100 (Fri, 15 Apr 2005)
Если вас интересует, как Subversion справляется с различиями между вашей работающей копией и той, которая содержится в репозитарии, вы будете приятно удивлены, узнав, что ответ кроется в папке .svn – административной директории. Здесь содержится вся необходимая Subversion информация для управления различиями 2-х версий дерева исходных текстов, например, расширения файлов и даты их модификации. Практически каждое ваше действие касательно Subversion отражается в административной директории, а ее редактирование вручную приведет только к лишним проблемам.
Добираемся до репозитория (врезка)
Путь к репозитарию зависит от протокола, который указывается в начале адреса:
| file:// | используется для прямого доступа к файлам, хранящимся в вашей файловый системе |
| http:// | протокол WebDAV, сконфигурированный на сервере Apache |
| https:// | то же самое, что и в предыдущем случае, но с добавлением SSL-шифрования |
| svn:// | родной протокол Subversion, поддерживаемый демоном svnserve |
| svn+ssh:// | протокол Subversion, дополненный SSH для обеспечения безопасности |
Часть 2 - изменяем файлы
После того, как вы загрузили собственную рабочую копию проекта, вы можете использовать команду svn status для проверки каких-либо изменений в репозитарии. Любой из модифицированных файлов будет представлен с буквой ‘M’, стоящей в первой колонке. Мы отредактировали простой пример helloworld.cpp, который скачали с нашего репозитария, и теперь, команда svn status должна отразить новый статус файла:
$ svn status M helloworld.cpp
В приведенном выше примере, файл helloworld.cpp был модифицирован в локальной копии. Вы можете проверить изменения между вашей локальной копией и копией в репозитарии, набрав команду svn diff. Эта команда работает в точности так же, как и всем известная команда diff, отображая также пути к двум деревьям исходных текстов.
$ svn diff
Index: helloworld.cpp
==========================================
--- helloworld.cpp (revision 1)
+++ helloworld.cpp (working copy)
@@ -5,6 +5,7 @@
int main(int argc, char *argv[])
{
cout << “Hello World!” << endl;
+ cout << «Это дополнение» << endl;
return(0);
}
Строка «Это дополнение» была помечена символом ‘+’ как измененная версия. По мере изменения файла, мы будем копировать новую версию в основной репозитарий, чтобы другие разработчики тоже могли пользоваться нашими нововведениями. Так же, как и в CVS, это делается командой svn commit, сопровождаемой комментарием для описания вносимых вами изменений. Хорошим тоном считается вносить как можно больше мелких изменений, используя вышеупомянутые комментарии для описания их сути. Таким образом, в дальнейшем будет проще отследить изменения, которые привели к неправильной работе программы, если что-то пойдет не так (а когда-нибудь это неизбежно произойдет).
$ svn commit Sending helloworld.cpp Transmitting file data . Committed revision 2.
Любому разработчику, который работает с этим же репозитарием и хотел бы получить файл с учетом ваших изменений, потребуется обновить свою рабочую копию, используя команду svn update. После этого у него будет точно такая же копия дерева исходных текстов, что и у вас.
$ svn update U helloworld.cpp Updated to revision 2.
Подсказка (врезка)
Графическое сравнение модификаций Нетрудно заметить пару отличий между двумя файлами, но ведь изменения могут быть и более сложными, и их может быть намного больше. В этом случае вы можете облегчить себе жизнь, используя графический просмотрщик отличий. Программа KDiff3 может показывать отличия нескольких файлов за один раз и даже поддерживает слияние. У KDE есть собственный просмотрщик под названием Kompare, который автоматически загружается при попытке открыть файл-патч. Для ясности, программа также показывает оригинальный файл с левой стороны, и подсвечивает, в каком именно месте он был модифицирован. С другой стороны показывается новая версия того же самого файла.
Реальный пример: обновляем Kopete при помощи Subversion (врезка)
Kopete – клиент для мгновенного обмена сообщениями, предлагаемый по умолчанию в KDE. Проблема в том, что его часто приходится обновлять. Несколько протоколов обмена сообщениями, используемых Kopete для связи с сервером и другими клиентами, разрабатываются путем инженерного анализа. Это единственный способ предоставить совместимость с такими протоколами, как AOL или MSN Messenger, которые порой таинственно и без огласки изменяются. Разработчики Kopete анализируют поток трафика между клиентом и сервером, впоследствии выпуская очередные обновления, которые сразу становятся доступными в репозитарии Subversion, а не в виде отдельных пакетов, так как на их организацию и сборку требуется определенное время.
Первое, что надо сделать для получения обновления к Kopete – подключиться к анонимному серверу KDE Subversion, который доступен для всех, кто осмелится ввести следующие команды:
$ svn co -N svn://anonsvn.kde.org/home/kde/trunk/ KDE/ kdenetwork
Вы получите много страниц кода, которые сопровождаются следующими строками:
Checked out revision 416028.
Программа Kopete является частью kdenetwork, а значит, она может быть найдена в соответствующей директории. Флаг –N в команде выше используется для скачивания отдельного каталога, а не всей ветки KDE со всеми ее поддиректориями. В результате загружаются файлы, относящиеся только к директории kdenetwork. Следующим шагом будет получение исходных текстов самой Kopete:
$ cd kdenetwork $ svn update kopete A kopete ... Updated to revision 416064.
Команда svn update загружает любые изменения между локальной копией и той, что хранится в репозитарии. Так как у нас сейчас нет локальной версии, результатом этой команды будет загрузка всей директории kopete. Каждый файл или директория отражаются в стандартном потоке вывода по мере их загрузки, обозначенные буквой ‘A’ в начале строки (‘U’ при обновлении файла и ‘D’ при удалении). Конечное сообщение всегда содержит номер ревизии, которую вы только что загрузили.
В репозитариях программного обеспечения обычно уже содержатся готовые сценарии, необходимые для компиляции и установки проекта, так что следующим шагом будет загрузка необходимых скриптов с директории kde-common. После этого мы можем вызвать команды для компиляции локальной копии программы Kopete:
$ svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kde-common/admin $ make -f Makefile.cvs $ ./configure --prefix=/usr $ make $ su -c “make install”
