Системы контроля версий - Курсовая работа

Курсовая работа по курсу «Информационные технологии» СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ В данной курсовой работе рассматриваются наиболее популярные системы контроля версий. Цель работы - познакомится с системами контроля версий, разобраться в их работе, установке и настройке. В результате три полностью готовые к работе системы контроля версий, составлены таблицы сравнения функций этих систем и приведен словарь терминов, используемых при работе с программами.Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты. Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов.Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение.Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. СКВ позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием.Каждая СКВ имеет свои специфические особенности в наборе команд, порядке работы пользователей и администрировании.Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо специальной команды, фактически выполняющей то же самое действие.При некоторых вариациях, определяемых особенностями системы и деталями принятого бизнес-процесса, обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом: 1) Обновление рабочей копии. По мере внесения изменений в основную версию проекта рабочая копия на компьютере разработчика стареет: расхождение ее с основной версией проекта увеличивается. Поэтому удобно поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, для чего разработчик выполняет операцию обновления рабочей копии (update) насколько возможно часто. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер, либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания.Однако при выполнении сколько-нибудь значительных по объему работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы.Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений: - Обновление рабочей копии; В каждой системе существует механизм автоматического слияния, который работает, основываясь на следующих принципах: - Изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте; Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически. Их объединение состоит в том, что изменения, сделанные в каждой версии проекта, копируются в объединяемую версию; Конфликтующими обычно являются: - Удаление и изменение одного и того же файла или каталога;Ситуация, когда при слиянии нескольких версий сделанные в них изменения пересекаются между собой, называют конфликтом. При конфликте изменений система управления версиями не может автоматически создать объединенный проект, и вынуждена обращаться к разработчику.Механизм блокировки позволяет одному из разработчиков взять только в собственное использование файл или группу файлов для внесения в них изменений. На то время, пока файл заблокирован, он остается доступным всем остальным разработчикам только на чтение, и любая попытка внести в него изменения отвергается сервером.

Содержание контроль версия система интерфейс

Введение

1. Понятие системы контроля версий

2. Использование системы контроля версий

3. Типичный порядок работы с системой

3.1 Начало работы с проектом

3.2 Ежедневный цикл работы

3.3 Ветвления

3.4 Слияние версий

3.5 Конфликты и их разрешение

3.6 Блокировки

3.7 Версии проекта, теги

4. Типы

4.1 Локальные системы контроля версий

4.2 Централизованная модель

4.3 Распределенные системы контроля версий

5. Примеры систем контроля версий

5.1 GIT

5.1.1 Требования к системе

5.1.2 Концепция

5.1.3 Начало работы

5.1.5 Создание копии репозитория

5.2 TORTOISESVN

5.2.1 Требования к системе

5.2.2 Установка

5.2.3 Основная концепция

5.2.4 Создание хранилища

5.2.5 Импорт проекта

5.2.6 Извлечение рабочей копии

5.2.7 Внесение изменений

5.2.8 Добавление новых файлов

5.2.9 Отмена изменений

5.2.10 Возможности TORTOISESVN. Интеграция с оболочкой

5.2.11 Графический интерфейс пользователя

5.3 Mercurial

5.3.1 Требования к системе

5.3.2 Концепция

5.3.3 Начало работы

5.3.4 Создание репозитория и работа с файлами

5.3.5 Создание копии репозитория

Заключение

Приложение А Приложение Б

Приложение В