Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы к экзамену.docx
Скачиваний:
261
Добавлен:
28.06.2014
Размер:
602.38 Кб
Скачать
  1. Системы управления версиями. Модели версионирования.

Основной задачей системы управления версиями является обеспечение совместного редактирования и распределения информации. Однако разные системы используют разные способы для достижения этого.

Проблема разделения файлов

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

Модель Блокирование-Изменение-Разблокирование

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

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

  • Блокирование может вызвать проблемы администрирования. Иногда Гарри заблокирует файл, а затем забудет об этом. Между тем, ожидая редактирования файла, у Салли будут связаны руки. А Гарри уехал в отпуск. Теперь Салли, для снятия блокировки Гарри, нужно обращаться к администратору. Ситуация заканчивается не нужной задержкой и потерянным временем.

  • Блокирование может вызвать излишнюю пошаговость. Что если Гарри редактирует начало текстового файла, а Салли нужно отредактировать концовку этого же файла? Эти изменения совсем не перекрываются. Они могли бы легко редактировать файл одновременно и никаких особенных проблем это не вызвало бы, предполагая корректное слияние изменений. Блокирование файла в такой ситуации не требуется.

  • Блокирование может вызвать ложное чувство безопасности. Предположим, что Гарри блокирует и редактирует файл А, в то время как Салли одновременно блокирует и редактирует файл В. Но допустим, что А и В зависят друг от друга и сделанные в каждом изменения семантически не совместимы. Неожиданно А и В больше не работают вместе. Блокирующая система бессильна в предотвращении проблемы — вместо этого она обеспечила ложное чувство безопасности. Для Гарри и Салли просто вообразить, что, блокируя файлы каждый начинает безопасную изолированную задачу и не беспокоиться в начале об обсуждении их несовместимых изменений.

Модель Копирование-Изменение-Слияние

Subversion, CVS и другие системы управления версиями пользуются моделью копирование-изменение-слияние в качестве альтернативы блокированию. В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию — локальное отражение файлов и каталогов хранилища. После этого пользователи работают параллельно, изменяя свои личные копии. В конце концов, личные копии сливаются в новую, финальную версию. Обычно система управления версиями помогает в слиянии, но, разумеется, за его корректное выполнение отвечает человек.

  1. Системы управления версиями. Rcs. Cvs.

RCS (Revision Control System) является одной из самых первых (разработана в 1985 году) систем управления версиями: для каждого файла, зарегистрированного в системе, она хранит полную историю изменений, причём для текстовых файлов используется эффективный алгоритм дельта-компрессии, когда хранится только последняя версия и все межверсионные изменения. Система позволяет также хранить версии бинарных файлов, но без использования этого механизма, то есть каждая версия бинарного файла хранится полностью.

Система RCS не имеет средств для коллективной работы над набором файлов — эти средства появились в системе-наследнице — CVS, использующей форматы и алгоритмы RCS для учёта версий, но имеющей также интерфейсы для коллективной работы.

Отсутствие коллективной работы на практике выглядит так, что только тот пользователь, который произвел действие «Lock» над файлом или файлами, может вносить изменения. Другие пользователи запросить эти же файлы на редактирование не могут.

CVS (Concurrent Versions System) — программный продукт, относящийся к разряду систем управления версиями (англ. version control system). Хранит историю изменений определённого набора файлов, как правило исходного кода программного обеспечения, и облегчает совместную работу группы людей (часто — программистов) над одним проектом. CVS популярна в мире открытого ПО. Система распространяется на условиях лицензии GNU GPL.

В настоящее время CVS является устаревшей системой, поскольку доступны более функциональные современные альтернативы (например, Subversion).

CVS использует архитектуру клиент-сервер. Обычно клиент и сервер соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. Серверное ПО обычно работает под управлением Unix (хотя существует CVS сервер и для Windows NT), тогда как CVS клиенты доступны во всех популярных операционных системах.

Сервер хранит в специальном хранилище (репозитории) текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить нужную ему версию или записать новую. Получив с сервера нужную версию (данная процедура называется check-out), клиент создаёт локальную копию проекта (или его части) — так называемую рабочую копию. После того как в файлы, находящиеся в рабочей копии, внесены необходимые изменения, они пересылаются на сервер (check-in).

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

Клиенты также могут сравнить различные версии файлов, запросить полную историю изменений или получить исторический образ проекта на определённое число или по номеру ревизии. Многие Open Source проекты разрешают анонимный доступ на чтение, который впервые был применён OpenBSD. Это означает, что клиенты могут запрашивать и сравнивать версии файлов без пароля; только check-in операции ведущие к изменению данных в репозитории требуют пароль.

Также для синхронизации локальной копии проекта с информацией на сервере клиенты могут использовать команду update, что позволяет избежать повторного скачивания всего проекта.

CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь (branch), в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии.

CVS использует механизм дельта-компрессии для эффективного хранения различных версий одного и того же файла.