МУ ОффС и УРП

МИНИСТЕРСТВО ПО ОБРАЗОВАНИЮ РОССИЙСКОЙ ФЕДЕРАЦИИ

РЯЗАНСКИЙ ГОСУДАРСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ОФИСНЫЕ СИСТЕМЫ И УТИЛИТЫ РАЗРАБОТКИ ПРИЛОЖЕНИЙ

Методические указания к лабораторным работам

Рязань 2010

Буквы «А» говорят о том, что элемент добавлен в вашу рабочую копию.

2.3. URL хранилища

Получить доступ к хранилищу Subversion можно через ряд сетевых протоколов. Местоположение хранилища всегда определяется с помощью URL (см. Таблицу).

URL для доступа к хранилищу

2.4. Фиксация (публикация) изменений в хранилище

Для публикации изменений следует воспользоваться командой commit:

$ svn commit button.c Sending button.c Transmitting file data . Committed revision 57.

2.5. Приведение рабочей копии в актуальное состояние

Для приведения рабочей копии в актуальное состояние используется команда Subversion update.

$ svn update U button.c

Updated to revision 57.

Вывод команды svn update говорит, что Subversion обновила содержимое button.c. Пользователь не должен указывать, какой файл обновить.

2.6. Правки

При фиксации создаётся новое состояние файловой системы - правка (ревизия). Каждая правка получает уникальный номер, на единицу больший номера предыдущей. Начальная правка только что созданного хранилища получает номер 0 и не содержит ничего, кроме пустого корневого каталога.

В служебном каталоге .svn/ для каждого файла рабочего каталога Subversion записывает информацию о двух важнейших свойствах:

− на какой правке основан рабочий файл (рабочая правка файла);

2

− временной метке, определяющей, когда рабочая копия последний раз обновлялась из хранилища.

Используя эту информацию при соединении с хранилищем, Subversion может сказать, в каком из следующих четырех состояний находится рабочий файл:

1)файл не изменялся и не устарел.

Файл не изменялся в рабочем каталоге, в хранилище не фиксировались изменения этого файла со времени создания его рабочей правки. Команды svn commit и svn update никаких операций делать не будут; 2) файл изменялся локально и не устарел.

Файл был изменен в рабочей копии, но в хранилище не фиксировались его изменения. Есть локальные изменения, которые не были зафиксированы в хранилище, поэтому svn commit выполнит фиксацию ваших изменений, а svn update не сделает ничего;

3) файл не изменялся и устарел.

В рабочем каталоге файл не изменялся, но был изменен в хранилище. Необходимо выполнить обновление файла для того, чтобы он соответствовал текущей правке. Команда svn commit не сделает ничего, а svn update обновит рабочую копию файла;

4) файл изменялся локально и устарел.

Файл был изменен как в рабочем каталоге, так и в хранилище. Svn commit выдаст ошибку «out-of-date». Файл необходимо сначала обновить; svn update попытается объединить локальные изменения с опубликованными. Если Subversion не сможет совершить объединение, она предложит пользователю разрешить конфликт вручную.

Для того чтобы узнать состояние любого элемента в вашей рабочей копии, существует команда svn status.

Фундаментальные правила Subversion - «передающее» действие не приводит к «принимаемому», и наоборот. То, что вы готовы внести изменения в хранилище, не означает, что вы готовы принять изменения от других. А если вы все еще работаете над новыми изменениями, то svn update объединит изменения из хранилища с вашими собственными вместо того, чтобы заставить вас опубликовать их.

Фактически каждый раз при выполнении svn commit правки рабочей копии смешиваются. Только что зафиксированные элементы отмечаются как имеющие больший номер рабочей правки, чем все остальные. После нескольких фиксаций (без выполнения обновлений между ними) правки рабочей копии будут полностью перемешаны. Даже если вы являетесь единственным пользователем хранилища, вы

3

все равно с этим столкнетесь. Для просмотра этой смеси рабочих правок воспользуйтесь командой svn status --verbose.

Смешивание правок имеет ограничения

Нельзя зафиксировать удаление устаревшего файла или каталога. Если в хранилище существует более новая версия элемента, попытка удаления будет отклонена.

Нельзя зафиксировать изменение метаданных для необновленного каталога.

2.7. Простейший рабочий цикл

Типичный рабочий цикл выглядит примерно так:

1)обновление рабочей копии: svn update

2)внесение изменений:

svn add (delete, copy, move)

3) редактирование файлов под контролем Subversion;

4)анализ изменений:

svn status (diff, revert)

5) слияние изменений, выполненных другими, с вашей рабо-

чей копией:

svn update svn resolved

6) фиксация изменений: svn commit

2.7.1. Обновление рабочей копии

При командной работе над проектом обновление рабочей копии необходимо для получения любых изменений, внесенных с момента вашего последнего обновления другими разработчиками проекта. Используйте svn update для синхронизации вашей рабочей копии с последней правкой в хранилище.

$ svn update U foo.c

Updated to revision 2.

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

Когда сервер отправляет изменения в рабочую копию, для каждого элемента выводится латинская буква — код, определяющий действие, выполненное Subversion для приведения рабочей копии в актуальное состояние:

4

−U (Updated) — файл получил изменения с сервера;

−A (Added) — файл добавлен в рабочую копию;

−D (Deleted) — файл удален из рабочей копии;

−R (Replaced) — файл был удален, а новый элемент с таким же именем был добавлен;

−G ( merGed) — произошло слияние изменений хранилища

сфайлом;

−C (Conflicting) — изменения с сервера конфликтуют с ва-

шими изменениями файла.

2.7.2. Внесение изменений в рабочую копию

Изменения, которые можно сделать в рабочей копии:

−изменения файлов;

−изменения в структуре.

Подкоманды, наиболее часто используемые при внесении изме-

нений:

−svn add <file> - запланировать для добавления в хранилище. При фиксации <file> станет компонентом своей родительской директории;

−svn delete <file> - запланировать удаление из хранилища

файла;

−svn copy <file1> <file2> - создать элемент <file2> как копию

<file1>;

−svn move <file1> <file2> - <file2> будет запланирован для добавления как копия <file1>, а <file1> будет запланирован для удаления.

2.7.3. Анализ изменений

Анализ перед фиксацией - хорошая возможность пересмотреть и проверить изменения перед их публикацией. Для этого используются команды svn status, svn diff и svn revert. Первые две команды находят измененные файлы рабочей копии, а третья позволяет отменить некоторые (или все) изменения.

2.7.4. Решение конфликтов (при объединении с

чужими изменениями)

Предположим, вы запустили svn update и произошло следую-

щее:

$ svn update

5

C <file>

Это значит, что изменения с сервера конфликтуют с вашими личными и теперь вам нужно вручную сделать между ними выбор.

Всякий раз, когда возникает конфликт, для того чтобы помочь вам заметить и решить этот конфликт, возникают, как правило, три

вещи: 1) Subversion печатает C во время обновления и запоминает, что файл в состоянии конфликта;

2) если Subversion считает, что файл объединяемого типа, она

помещает маркеры конфликта в файл, чтобы показать пересекающиеся области;

3) для каждого конфликтного файла Subversion добавляет в рабочую копию до трех неверсионированных дополнительных файлов:

бочей копии);

−filename.rNEWREV - файл правки HEAD (после обновле-

ния).

Для решения конфликта предусмотрены три варианта:

1) объединить конфликтующий текст «вручную» (путем анализа и редактирования маркеров конфликта в файле);

2) скопировать один из временных файлов поверх своего рабочего файла;

3) выполнить svn revert <filename> для того, чтобы убрать все

ваши локальные изменения.

После разрешения конфликта нужно выполнить svn resolved. Это удаляет три временных файла и разрешает конфликт.

2.7.5. Объединение конфликтов вручную

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

<<<<<<< .mine //начало вашего текста //конец вашего текста

=======

// начало чужого текста

6

//конец чужого текста

>>>>>>> .r2

Строки знаков «<», знаков «=» и знаков «>» являются маркерами конфликта. Перед следующей фиксацией надо удалить их из файла

ивыполнить svn resolved.

2.7.6.Копирование файла поверх вашего рабочего файла

Если решено отказаться от своих изменений, то можно скопировать один из временных файлов, созданных Subversion поверх файла в рабочей копии.

2.7.7. Использование svn revert

Если в результате конфликта надо отбросить изменения и начать сначала, следует отменить изменения:

$ svn revert <File>

2.7.8. Фиксация изменений

Команда svn commit отправляет все ваши изменения в хранилище. При фиксации изменений необходимо указать описывающие ваши изменения сообщение.

$ svn commit --message " The corrected list of surnames of work-

ers."

3.Практическая часть

1.Создать каталоги для хранилища и двух рабочих копий.

2.Создать в хранилище 0-ю ревизию проекта.

3.Создать рабочую копию в 1-м рабочем каталоге.

4.В каталоге первой рабочей копии создать 3 текстовых файла.

5.В каталоге первой рабочей копии поставить под контроль 1

файл.

6.В каталоге второй рабочей копии создать рабочую копию.

7.В первой рабочей копии сделать фиксацию.

8.Во второй рабочей копии забрать файлы из хранилища.

9.В первой рабочей копии взять под контроль 2-й файл.

10.Фиксировать 1-ю рабочую копию.

11.Во второй рабочей копии взять под контроль 3-й файл.

12.В первой рабочей копии снять контроль с 3-го файла.

13.Фиксировать 1-ю рабочую копию.

14.В первой рабочей копии редактировать 1-й файл.

15.Фиксировать первую рабочую копию.

16.Просмотреть историю изменений.

17.Создать конфликты путем редактирования файла 3 в обеих рабочих копиях (сначала отредактировать непересекающиеся части файла, затем пересекающиеся).

7

18.Посмотреть реакцию системы.

19.Разрешить конфликты всеми возможными способами.

20.Исследовать, когда конфликт получается, а когда нет.

4.Содержание отчета

Отчет должен содержать:

−описание структуры хранилища и резервных копий;

−содержание текстовых файлов в различных ревизиях;

−все файлы, появившиеся в результате конфликта;

−анализ конфликта;

−выполняемые команды с комментариями и результаты их выполнения.

5. Контрольные вопросы

1.Достоинства Subversion.

2.Причины возникновения конфликтов.

3.Момент обнаружения конфликта пользователем.

4.Значение ключевого слова NEWREV.

5.После операции svn update имеем G file1. Значение данного

статуса.

6.Откуда берется копия файла для замены при осуществлении команды svn revert?

7.Назовите три варианта использования команды svn diff.

8.Команда, показывающая содержание директории хранилища, не закачивая его в рабочую копию.

9.Быстрый способ скопировать неверсионированное дерево в хранилище.

10.Действия, вызванные svn commit и svn update, при условии,

что файл изменялся локально и устарел.

11. Фундаментальное правило смешения правок в рабочих ко-

пиях.

12. Какое максимальное значение изменений файлов и каталогов может опубликовать svn commit за одну атомарную операцию?

Лабораторная работа № 2 Subversion. Ветвление

1. Цель работы

Получение базовых знаний о ветвлении, получение навыков его практического применения.

Продолжительность работы: 4 часа.

2. Теоретическая часть Ветвление в Subversion

8