Иван Немытченко
,
GitLab
Облегчить себе жизнь при совместной разработке программных продуктов.
Александр Макарчук
,
qb
Оптимизация командной разработки.
Петр Урваев
,
SimbirSoft
В ходе разработки код проекта активно меняется. При этом нужно вести учет того, что уже было сделано, и согласовывать действия отдельных участников по одновременному изменению кода так, чтобы доработки участников проекта учитывали все ранее сделанные правки других участников. Система контроля версий позволяет автоматизировать этот процесс.
2. Какие факторы влияют на выбор системы контроля версий?
Николай Фетюхин
,
MST
Поддержка ядра системы контроля версий и ее конкретной реализации, знакомство с ней команды. Чаще всего используется одна система на все проекты. Исключениями могут быть, например, требования заказчика.
Иван Немытченко
,
GitLab
Популярность той или иной системы, из которой следует уже все остальное: поддержка в приложениях и сервисах, количество и качество документации, наличие эксперта «под боком» и т.п.
Александр Макарчук
,
qb
В нашем случае выбор основывается на популярности системы контроля версий и уровне владения ей разработчиками.
Петр Урваев
,
SimbirSoft
В первую очередь - соответствие возможностей системы контроля версий принятому в команде процессу разработки. Во вторую очередь, то с какой системой контроля версий привычнее работать участникам проекта.
3. Как внедрить использование системы контроля версий в команде?
Николай Фетюхин
,
MST
Сейчас даже современные студенты уже выпускаются с общим пониманием, для чего необходимы системы контроля версий, поэтому вопрос внедрения не совсем корректен. Обычно все проекты просто по умолчанию начинаются с создания репозитория. Если же в общем случае, то следует поговорить с командой, выяснить почему системы контроля версий на проекте нет (изредка бывают различные крайне специфические случаи), и если проблемы преодолимы, то провести пару семинаров внутри команды по конкретной системе контроля версий (если требуется) и запускаться.
Иван Немытченко
,
GitLab
Дать им возможность поработать без системы контроля версий, чтобы прочувствовали всю боль. Потом «подсунуть» им cheatsheet по Git-у, и они сами все выучат и внедрят. Но так можно работать со школьниками и студентами. У зрелых разработчиков обычно этот вопрос не стоит.
Александр Макарчук
,
qb
Медленно, но верно каждый приходит к этому самостоятельно.
Петр Урваев
,
SimbirSoft
В большинстве современных проектов необходимость использования системы контроля версий не вызывает вопросов. При обучении работе с ней достаточно настроить ее для удобной работы и прочитать короткую лекцию об основных возможностях используемой системы контроля версий с приведением примеров использования.
4. Благодаря чему Git стал стандартом в мире систем контроля версий? Сможет ли его кто-то сместить с лидирующего положения?
Николай Фетюхин
,
MST
Git изначально содержал несколько полезных вещей, таких как локальные коммиты, а также решил большое количество проблем со слиянием веток, которыми был богат предыдущий законодатель мод - Subversion (SVN). С самого начала он боролся за популярность с Mercurial (Hg), который в некоторых аспектах проще, но в итоге вырвался в лидеры.
Иван Немытченко
,
GitLab
Благодаря тому, что Линус Торвальдс атаковал проблему распределенной разработки с правильной стороны, учтя недостатки систем-предшественников. Сместить? А зачем?
Александр Макарчук
,
qb
Благодаря тому, что Git - молодец. Очень долго никто его не сместит.
Петр Урваев
,
SimbirSoft
Основное преимущество Git - развитость инструментов для работы с ним и возможность хранения в нем результатов работы по нескольким параллельно открытым задачам так, что промежуточные результаты не влияют друг на друга, и при этом окончательные результаты можно достаточно легко скомбинировать в одну итоговую версию приложения. Также немаловажную роль во всеобщей популярности Git’a в мире CVS сыграл ресурс GitHub, на котором размещены тысячи репозиториев на различных языках.
5. Что не устраивает разработчиков в Git? Почему некоторые выбирают другие менее популярные решения?
Николай Фетюхин
,
MST
Единственный значимый для нас недостаток Git - это некоторые проблемы с отслеживанием изменений: ветки могут быть удалены, и может остаться только merge-коммит. Это связано во многом с тем, что у Git ветки привязаны к коммитам. Также у Git более крутая кривая обучения, чем у упомянутого выше Mercurial или Subversion.
Александр Макарчук
,
qb
В рамках наших задач всем устраивает.
Петр Урваев
,
SimbirSoft
Git достаточно удобен, но требует изучения (теми, кто его еще не знает) и активных действий по переходу на него, поэтому некоторые команды предпочитают оставаться на используемых ими системах контроля версий. Также выбор системы контроля версий может быть определен используемыми инструментами разработки.
6. Насколько распространено использование систем контроля версий для управления другими файлами, а не только кодом?
Николай Фетюхин
,
MST
В настоящее время повсеместно. Те же облачные системы вроде One Drive, Яндекс.Диск, Dropbox и Google Drive в основе содержат идеологию, повторяющую системы контроля версий.
На практике использование обычных систем контроля версий для хранения документов распространено, но не слишком, тонкости возникают с расчетом изменений, так как большинство современных распространенных форматов документов являются бинарными, и их наборы изменений не человекочитаемы.
Александр Макарчук
,
qb
Постоянно используется.
Петр Урваев
,
SimbirSoft
Системы контроля версий нацелены в первую очередь на работу с большим количеством небольших файлов, что используется в основном в разработке. Использование подобных систем для файлов нетекстовых форматов (бинарных), как правило, неэффективно, а в некоторых случаях и вовсе невозможно. Поэтому для хранения других файлов используются обычно специализированные системы, адаптированные под работу с определенными форматами данных.
Система управления версиями (от англ. Version Control System - VCS, или Revision Control System) - специальное программное обеспечение для работы с часто изменяющейся информацией, позволяет хранить несколько версий одного и того же документа и при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, а также многое другое.
Такие системы наиболее широко используются при разработке программного обеспечения для хранения файлов разрабатываемой программы.
Часто бывает, что над одним проектом одновременно работают несколько человек, и если два человека изменяют один и тот же файл, то один из них может случайно отменить изменения, сделанные другим. Системы управления версиями отслеживают такие конфликты и предлагают средства их решения. Большинство таких систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако такое автоматическое объединение изменений обычно возможно только для текстовых файлов и при условии, что изменялись разные (непересекающиеся) части этого файла. Это ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.
Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла (например, средствами файловой системы) и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом.
Большинство систем управления версиями предоставляют следующие возможности:
Каждая система управления версиями имеет свои специфические особенности в наборе команд, порядке работы пользователей и администрировании. Тем не менее общий порядок работы для большинства VCS совершенно стереотипен. Здесь предполагается, что проект, каким бы он ни был, уже существует и на сервере размещен его репозиторий, к которому разработчик получает доступ.
Начало работы с системой. Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо с помощью специальной команды, фактически выполняющей то же самое действие. Разработчик задает версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.
Ежедневный цикл работы. Обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом:
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное
Учреждение высшего профессионального образования
«ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ» (ТУСУР)
Кафедра радиотехнических систем (РТС)
по курсу «Информационные технологии»
СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ
Студенты гр.121-3 Королев Д.О.,
Кулешов М.В., Садов Д.А., Таймасов С.С.
Руководитель Ноздреватых Б.Ф
Курсовая работа 46с., 31 рис., 2 табл., источников.
СИСТЕМА КОНТРОЛЯ ВЕРСИЙ, GIT, SVN, MERCURIAL.
В данной курсовой работе рассматриваются наиболее популярные системы контроля версий.
Цель работы - познакомится с системами контроля версий, разобраться в их работе, установке и настройке.
В процессе работы производилась установка трех видов систем контроля версий с их настройкой и тестированием работы.
В результате три полностью готовые к работе системы контроля версий, составлены таблицы сравнения функций этих систем и приведен словарь терминов, используемых при работе с программами.
Курсовая работа выполнена в текстовом редакторе Microsoft Word 2010 и представлена в печатном и электронном виде.
контроль версия система интерфейс
Введение
3.1 Начало работы с проектом
3.2 Ежедневный цикл работы
3.3 Ветвления
3.4 Слияние версий
3.5 Конфликты и их разрешение
3.6 Блокировки
3.7 Версии проекта, теги
4.1 Локальные системы контроля версий
4.2 Централизованная модель
5.1.1 Требования к системе
5.1.2 Концепция
5.1.3 Начало работы
5.2.1 Требования к системе
5.2.2 Установка
5.2.3 Основная концепция
5.2.4 Создание хранилища
5.2.5 Импорт проекта
5.2.7 Внесение изменений
5.2.8 Добавление новых файлов
5.2.9 Отмена изменений
5.3.1 Требования к системе
5.3.2 Концепция
5.3.3 Начало работы
Заключение
Приложение А
Приложение Б
Приложение В
Введение
Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. За время своего существования электронный документ может быть подвержен большому количеству изменений. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты.
Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов.
Вследствие этого были разработаны программные средства, которые упрощают данный механизм. Данные средства именуются системами контроля версий. Существует несколько систем такого рода, каждая из которых актуальна при определенных условиях их использования.
Основная идея систем контроля версий - запоминать все внесенные изменения, а так же комментарии пользователей, их вносивших. После этого становится понятно кто, когда и что менял, зачем и почему. И, что немаловажно, все эти изменения можно потом откатить на любой момент времени.
В соответствии с поставленной целью необходимо решить следующие задачи:
Определить понятие системы контроля версий;
Понять, как работают такие системы;
Рассмотреть правила установки и запуска;
Проанализировать существующие системы контроля версий;
Рассмотреть основные виды данного рода систем.
Задачи работы предопределили ее структуру. Курсовая работа состоит из пяти глав, введения, заключения, списка литературы и приложения.
1. Понятие системы контроля версий
Система контроля версий (СКВ) -- программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение.
2. Использование системы контроля версий
Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. СКВ позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием. Но, тем не менее, данные системы могут использоваться и в других областях знаний, которые включают в себя огромное количество часто изменяющихся электронных документов. Например, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления.
Использование СКВ, безусловно, обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков.
Системы контроля версий решают следующие проблемы:
Хранение версий файлов;
Возможность получить любые предыдущие версии хранимых файлов;
Просмотр изменений внесенных между заданными в запросе версиями;
3. Типичный порядок работы с системой
Каждая СКВ имеет свои специфические особенности в наборе команд, порядке работы пользователей и администрировании. Тем не менее, общий порядок работы для большинства СКВ совершенно стереотипен. Здесь предполагается, что проект, каким бы он ни был, уже существует и на сервере размещён его репозиторий, к которому разработчик получает доступ.
Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо специальной команды, фактически выполняющей то же самое действие. Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.
По команде извлечения устанавливается соединение с сервером, и проект в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была сделана рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения СКВ.
При некоторых вариациях, определяемых особенностями системы и деталями принятого бизнес-процесса, обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом:
1) Обновление рабочей копии. По мере внесения изменений в основную версию проекта рабочая копия на компьютере разработчика стареет: расхождение её с основной версией проекта увеличивается. Это повышает риск возникновения конфликтных изменений. Поэтому удобно поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, для чего разработчик выполняет операцию обновления рабочей копии (update) насколько возможно часто.
2) Модификация проекта. Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием. Эта работа производится локально и не требует обращений к серверу СКВ.
3) Фиксация изменений. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер, либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания. СКВ может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в СКВ это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.
Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), создание версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в основную ветвь. Это может делаться командой слияния (merge), либо путём создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.
Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений:
Обновление рабочей копии;
Фиксация изменений;
Слияние ветвей.
В каждой системе существует механизм автоматического слияния, который работает, основываясь на следующих принципах:
Изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте;
Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически. Их объединение состоит в том, что изменения, сделанные в каждой версии проекта, копируются в объединяемую версию;
Создание, удаление и переименование файлов в каталогах проекта могут быть объединены автоматически, если только они не конфликтуют между собой. В этом случае изменения, сделанные в каждой версии проекта, копируются в объединяемую версию.
Конфликтующими обычно являются:
Удаление и изменение одного и того же файла или каталога;
Удаление и переименование одного и того же файла или каталога;
Создание в разных версиях файла с одним и тем же именем и разным содержимым;
Изменения в пределах одного текстового файла, сделанные в разных версиях, могут быть объединены, если они находятся в разных местах этого файла и не пересекаются. В этом случае в объединённую версию вносятся все сделанные изменения;
Изменения в пределах одного файла, если он не является текстовым, всегда являются конфликтующими и не могут быть объединены автоматически.
Во всех случаях базовой версией для слияния является версия, в которой было произведено разделение сливаемых версий. Если это операция фиксации изменений, то базовой версией будет версия последнего обновления перед фиксацией, если обновление -- то версия предыдущего обновления, если слияние ветвей -- то версия, в которой была создана соответствующая ветвь. Соответственно, сопоставляемыми наборами изменений будут наборы изменений, сделанных от базовой до текущей версии во всех объединяемых вариантах.
Абсолютное большинство современных систем управления версиями ориентировано, в первую очередь, на проекты разработки программного обеспечения, в которых основным видом содержимого файла является текст. Соответственно, механизмы автоматического слияния изменений ориентируются на обработку текстовых файлов.
При определении допустимости слияния изменений в пределах одного и того же текстового файла работает типовой механизм построчного сравнения текстов (примером его реализации является системная утилита GNU diff), который сравнивает объединяемые версии с базовой и строит список изменений, то есть добавленных, удалённых и заменённых наборов строк. Найденные наборы изменённых строк, которые не пересекаются между собой, считаются совместимыми и их слияние делается автоматически. Если в сливаемых файлах находятся изменения, затрагивающие одну и ту же строку файла, это приводит к конфликту. Такие файлы могут быть объединены только вручную. Любые файлы, кроме текстовых, с точки зрения СКВ являются бинарными и не допускают автоматического слияния.
Ситуация, когда при слиянии нескольких версий сделанные в них изменения пересекаются между собой, называют конфликтом. При конфликте изменений система управления версиями не может автоматически создать объединённый проект, и вынуждена обращаться к разработчику. Как уже говорилось выше, конфликты могут возникать на этапах фиксации изменений, обновления или слияния ветвей. Во всех случаях при обнаружении конфликта соответствующая операция прекращается до его разрешения.
Для разрешения конфликта система, в общем случае, предлагает разработчику три варианта конфликтующих файлов: базовый, локальный и серверный. Конфликтующие изменения либо показываются разработчику в специальном программном модуле объединения изменений, либо просто помечаются специальной разметкой прямо в тексте объединённого файла.
Конфликты в файловой системе разрешаются проще: там может конфликтовать только удаление файла с одной из прочих операций, а порядок файлов в каталоге не имеет значения, так что разработчику остаётся лишь выбрать, какую операцию нужно сохранить в сливаемой версии.
Механизм блокировки позволяет одному из разработчиков взять только в собственное использование файл или группу файлов для внесения в них изменений. На то время, пока файл заблокирован, он остаётся доступным всем остальным разработчикам только на чтение, и любая попытка внести в него изменения отвергается сервером. Технически блокировка может быть организована по-разному. Типичным для современных систем является следующий механизм:
Файлы, для работы с которыми требуется блокировка, помечаются специальным флагом «блокируемый»;
Если файл помечен как блокируемый, то при извлечении рабочей копии с сервера он получает в локальной файловой системе атрибут «только для чтения», что препятствует его случайному редактированию;
Разработчик, желающий изменить блокируемый файл, вызывает специальную команду блокировки (lock) с указанием имени этого файла. В результате работы этой команды происходит следующее:
1. сервер проверяет, не заблокирован ли уже файл другим разработчиком; если это так, то команда блокировки завершается с ошибкой.
2. файл на сервере помечается как «заблокированный», с сохранением идентификатора заблокировавшего его разработчика и времени блокировки;
3. если блокировка на сервере прошла удачно, на локальной файловой системе с файла рабочей копии снимается атрибут «только для чтения», что позволяет начать его редактировать.
Если в процессе работы выясняется, что файл изменять не нужно, он может вызвать команду снятия блокировки (unlock, release lock). Все изменения файла будут отменены, локальный файл вернётся в состояние «только для чтения», с файла на сервере будет снят атрибут «заблокирован» и другие разработчики получат возможность изменять этот файл;
По завершении работы с блокируемым файлом разработчик фиксирует изменения. Обычно блокировка при этом снимается автоматически.
Система управления версиями обеспечивает хранение всех существовавших вариантов файлов и, как следствие, всех вариантов проекта в целом, имевших место с момента начала его разработки. Но само понятие «версии» в разных системах может трактоваться двумя различными способами.
Одни системы поддерживают версионность файлов. Это означает, что любой файл, появляющийся в проекте, получает собственный номер версии. При каждой фиксации разработчиком изменений, затрагивающих файл, соответствующая часть фиксируемых изменений применяется к файлу, и файл получает новый, обычно следующий по порядку, номер версии.
Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера. Номера версии отдельного файла здесь, фактически, не существует.
Однако оба варианта не слишком удобны. Для более удобной пометки версий проекта системы контроля версиями поддерживают понятие тегов.
Тег - это символическая метка, которая может быть связана с определённой версией файла и/или каталога в репозитории. С помощью соответствующей команды всем или части файлов проекта, отвечающим определённым условиям может быть присвоена заданная метка. Таким образом можно идентифицировать версию проекта, зафиксировав его состояние на некоторый желаемый момент. Как правило, система тегов достаточно гибкая и позволяет пометить одним тегом и не одновременные версии файлов и каталогов. Это позволяет собрать «версию проекта» любым произвольным образом.
Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет бомльшую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, так называемая «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время.
Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный -- централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё -- всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные СКВ подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.
Такие системы используют распределённую модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. Поэтому в случае, когда отключается сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами между пользователями.
Описанная модель логически близка созданию отдельной ветки для каждого разработчика в классической системе управления версиями. Отличие состоит в том, что до момента синхронизации другие разработчики этой ветви не видят. Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. По завершении обособленной части работы, внесённые в ветви изменения сливают с основной (общей) ветвью. Как при слиянии ветвей, так и при синхронизации разных хранилищ возможны конфликты версий. На этот случай во всех системах предусмотрены те или иные методы обнаружения и разрешения конфликтов слияния.
С точки зрения пользователя распределённая система отличается необходимостью создавать локальный репозиторий и наличием в командном языке двух дополнительных команд: команды получения репозитория от удалённого компьютера и передачи своего репозитория на удалённый компьютер. Первая команда выполняет слияние изменений удалённого и локального репозиториев с помещением результата в локальный репозиторий; вторая -- наоборот, выполняет слияние изменений двух репозиториев с помещением результата в удалённый репозиторий. Как правило, команды слияния в распределённых системах позволяют выбрать, какие наборы изменений будут передаваться в другой репозиторий или извлекаться из него, исправлять конфликты слияния непосредственно в ходе операции или после её неудачного завершения, повторять или возобновлять неоконченное слияние. Обычно передача своих изменений в чужой репозиторий завершается удачно только при условии отсутствия конфликтов. Если конфликты возникают, пользователь должен сначала слить версии в своём репозитории, и лишь затем передавать их другим.
Обычно рекомендуется организовывать работу с системой так, чтобы пользователи всегда или преимущественно выполняли слияние у себя в репозитории. То есть, в отличие от централизованных систем, где пользователи передают свои изменения на центральный сервер, когда считают нужным, в распределённых системах более естественным является порядок, когда слияние версий инициирует тот, кому нужно получить его результат (например, разработчик, управляющий сборочным сервером).
Основные преимущества распределённых систем -- их гибкость и значительно бомльшая (по сравнению с централизованными системами) автономия отдельного рабочего места. Каждый компьютер разработчика является, фактически, самостоятельным и полнофункциональным сервером, из таких компьютеров можно построить произвольную по структуре и уровню сложности систему, задав желаемый порядок синхронизации.
К недостаткам распределённых систем можно отнести увеличение требуемого объёма дисковой памяти: на каждом компьютере приходится хранить полную историю версий, тогда как в централизованной системе на компьютере разработчика обычно хранится лишь рабочая копия, то есть срез репозитория на какой-то момент времени и внесённые изменения. Менее очевидным, но неприятным недостатком является то, что в распределённой системе практически невозможно реализовать некоторые виды функциональности, предоставляемые централизованными системами. Это:
Крупный распределённый проект, участники которого могут долгое время работать каждый над своей частью, при этом не имеют постоянного подключения к сети. Такой проект может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможна работа и без «групповых» серверов, тогда разработчики одной группы синхронизируют изменения между собой, после чего любой из них передаёт изменения на центральный сервер.
5. Примеры систем контроля версий
Git является распределённой системой контроля версий. В нем файлы могут находиться в одном из трёх состояний: зафиксированном, изменённом и подготовленном. "Зафиксированный" значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы - это изменённые файлы, отмеченные для включения в следующий коммит.
Git add ex.txt
Git commit -m "комментарий"
Git remote add origin https://github.com/Arbuz-z-z/MyHomework.git
Git push -u origin master
Команда git remote add - добавление удалённых репозиториев, а команда git push - отправление локальных изменений на удаленный сервер.
Рисунок 5.1.7
Вводим логин и пароль указанные при регистрации:
Рисунок 5.1.8
Теперь наш проект размещён на GitHub"е, в репозитории - MyHomework с файлом Tusur.txt и мы можем дать ссылку на него любому, с кем захотим разделить проект.
Рисунок 5.1.9 Репозиторий на GitHub"е
Хранилище. Subversion использует центральную базу данных, которая содержит все версированные файлы с их полной историей. Эта база данных называется хранилищем. Хранилище обычно находится на файловом сервере, на котором установлен Subversion, по запросу поставляющий данные клиентам Subversion (например, TortoiseSVN). Если вы делаете резервное копирование, то копируйте ваше хранилище, так как это оригинал всех ваших данных.
Рабочая копия. Это именно то место, где вы работаете. Каждый разработчик имеет собственную рабочую копию, иногда называемую песочницей, на своем локальном компьютере. Вы можете получить из хранилища последнюю версию файлов, поработать над ней локально, никак не взаимодействуя с кем-либо еще, а когда вы будете уверены в изменениях, вы можете зафиксировать эти файлы обратно в хранилище. Рабочая копия не содержит историю проекта, но содержит копию всех файлов, которые были в хранилище до того, как вы начали делать изменения.
Сначала создадим новую пустую директорию на ПК. Она может быть где угодно, но в этой работе мы собираемся назвать её s:\svn_repos. Теперь сделав правый клик на новой папке и в контекстном меню выберем TortoiseSVN > Создать здесь хранилище... Хранилище, созданное внутри папки, готово к использованию. Также мы создадим внутреннюю структуру папок, нажав кнопку «Создать структуру каталогов».
К хранилищу Subversion обращаются по URL-адресу, который позволяет нам указать хранилище где угодно в Интернете. В данном случае нам нужно указать на наше локальное хранилище, которое имеет URL-адрес file:///s:/svn_repos, и к которому мы добавляем имя нашего проекта TortoiseSVN.
Другая важная функция данного диалога - это окно Сообщение импорта, в которое можно добавить сообщение о том, что мы делаем. Когда нам понадобится просмотреть историю проекта, эти сообщения будут ценным подспорьем для просмотра какие изменения и когда были сделаны.
Сейчас у нас есть проект в нашем хранилище, и нам надо создать рабочую копию для повседневной работы. Стоит отметить, что импортирование папки не превращает автоматически эту папку в рабочую копию. Для создания свежей рабочей копии в Subversion используется термин «Извлечь». Мы собираемся извлечь папку TortoiseSVN из нашего хранилища в папку для разработки называемую e:\ \TortoiseSVN\svn_repos. Создадим эту папку, затем сделаем правый клик на ней и выберите пункт TortoiseSVN > Извлечь... Введите URL-адрес для извлечения, в данном случае file:///s:/svn_repos/TortoiseSVN, и кликните на OK. Наша папка для разработки заполнится файлами из хранилища.
Рисунок 5.2.5 Сравнение файлов
Теперь обновим хранилище. Это действие называется «Фиксировать изменения». Нажмём правой кнопкой на папке TortoiseSVN и выберем команду TortoiseSVN > Фиксировать. Появится диалог фиксации со списком изменённых файлов и напротив каждого будет галочка. Мы можем выбрать лишь несколько файлов из списка для фиксации.
Рисунок 5.2.6 Фиксация файлов
Во время работы над проектом, нам понадобится добавлять новые файлы, предположим мы добавили новые функции в файле и добавили справку в существующем файле. Нажмём правой кнопкой на папке и выберите команду TortoiseSVN > Добавить. Диалог добавления показывает все неверсированные файлы и мы можем выбрать те файлы, которые мы хотим добавить. Другой способ добавления файлов - это нажать правой кнопкой на самом файле и выбрать команду TortoiseSVN > Добавить.
Если мы хотим избавиться от изменений, которые мы еще не успели фиксировать и восстановить нужный файл в том виде, в котором он был перед началом изменений, то выберем команду TortoiseSVN > Убрать изменения. Это действие отменит наши изменения и вернет фиксированную версию файла, с которой мы начинали. Если же мы хотим убрать лишь некоторых изменения, то мы можете использовать инструмент TortoiseMerge для просмотра изменений и выборочного удаления измененных строк.
И вам даже не обязательно использовать именно Проводник. Контекстные меню TortoiseSVN работают во многих других файловых менеджерах, и в диалогах для открытия файлов, используемых в большинстве стандартных Windows-приложений. Однако вы должны учитывать, что TortoiseSVN изначально разработан как расширение для Проводника Windows, и, возможно, в других приложениях интеграция будет не полной, например, могут не отображаться пометки на значках.
1. На личном компьютере создается новый репозиторий (путем клонирования существующего репозитория, создания нового и т. п.);
2. В рабочей директории данного репозитория изменяются/добавляются/удаляются файлы;
3. Выполняется фиксация (commit) изменений в данный репозиторий (то есть в локальный репозиторий на личном компьютере);
4. Шаги 2 и 3 повторяются столько раз, сколько необходимо;
5. При необходимости производится синхронизация изменений с другими репозиториями: забираются (pull) чужие наборы изменений и/или отдаются (push) собственные.
То есть вся повседневная работа происходит в локальном репозитории, а когда возникает необходимость, производится отправка результатов своей работы в один или несколько других репозиториев. Количество шагов при работе с отдаленными репозиториями можно сократить, если настроить Mercurial на автоматическую отправку изменений в другие репозитории при выполнении фиксации.
Убедимся, что Mercurial видит сохраненный файл. По команде status выводится состояние рабочей копии в сравнении с состоянием локального репозитория. Mercurial показывает, что видит файл example.txt, но этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). Для того, чтобы сказать Mercurial, что его необходимо версионировать, выполним hg add. Слева от имени файла появляется символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите (при создании новой ревизии), который выполняется командой hg commit.
В первый раз выполнение команды hg commit может пройти неудачно. Mercurial записывает ваше имя и адрес в каждую ревизию, чтобы вы или другие пользователи могли связаться с автором каждого изменения. Чтобы установить имя пользователя следует внести изменения в расположенный в каталоге.hg внутри рабочей директории файл hgrc. Первоначальное содержание этого файла должно выглядеть примерно так:
Строка «» объявляет секцию конфигурационного файла. Вы можете прочитать «username =...» как «установить значение переменной username в секции ui». Секции продолжаются до начала новых секций. Пустые строки и строки, начинавшиеся с «#» игнорируются. Вы можете использовать любой текст в качестве значения username, так как эта информация предназначена для других людей, а не для интерпретации Mercurial"ом. В примере выше для этого использовалось распространенное соглашение: комбинация имени и адреса электронной почты.
Когда мы фиксируем изменения, Mercurial переводит нас в текстовый редактор, чтобы ввести комментарий, описывающий модификации, которые мы внесли в этом наборе изменений. Такое описание называется сообщением об изменениях (описанием изменений, описанием ревизии). Это будет записью для читателей о том, что мы сделали и почему, и будет выводиться при выполнении команды hg log после того, как мы закончим публикацию ревизии.
Mercurial игнорирует строки, начинающиеся с «HG:». Он использует их только для того, чтобы сообщить нам, изменения в каких файлах он запишет. Редактирование или удаление этих строк ни на что не повлияет. Если вы передумаете публиковать изменения во время редактирования комментария, просто выйдите из редактора без сохранения изменяемого файла. Это не вызовет изменений ни в репозитории, ни в рабочем каталоге.
Команда hg log по умолчанию выводит только первую строку описания изменений. Поэтому комментарий лучше написать так, чтобы первая строка была отделена. Для оставшейся части описания ревизии нет жестких правил. Сам Mercurial не обрабатывает и не заботится о содержимом сообщения об изменениях, хотя в вашем проекте могут быть правила, предписывающие определённое форматирование.
Хотя вы можете скопировать репозиторий как обычный каталог, лучше использовать встроенную команду Mercurial. Она называется hg clone, потому что создает идентичную копию существующего репозитория. Одно из преимуществ использования hg clone в том, что она позволяет клонировать репозитории по сети. Другим является то, что она запоминает, откуда мы его клонировали.
Каждый репозиторий Mercurial полон, самодостаточен и независим. Он содержит свою собственную копию файлов проекта и их историю. Клонированный репозиторий помнит, откуда он был клонирован, но не общается с тем репозиторием, да и ни с каким другим тоже, до тех пор пока вы ему не скажете. Следовательно, вы можете свободно экспериментировать с вашим репозиторием. Это безопасно, потому что ваш репозиторий -- «закрытая песочница», изменения в котором не повлияют ни на что, кроме него самого.
Mercurial позволяет передать изменения в другой репозиторий из репозитория, в котором мы в данный момент находимся. Добавим новую ревизию (под комментарием local change) в исходный репозиторий и выполним команду Хранилище\Синхронизация\Протолкнуть. Интерфейс рабочей среды позволяет выбрать только те ревизии, которые необходимо «протолкнуть». Обратим внимание, что в репозитории remote-vault была создана новая ветвь для полученной ревизии.
...Возможности системы контроля версий - программы, предназначенной для работы с изменяющимися документами. Ее свойства и практики использования. Внутреннее устройство хранилища. Рабочая копия версионируемых документов. Централизованные и распределённые СКВ.
презентация , добавлен 05.01.2014
Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.
дипломная работа , добавлен 21.12.2012
Анализ архитектуры ОС Windows 8. Сравнение с предыдущими версиями (интерфейс Modern UI, работа с учетными записями, модель безопасности, диспетчер задач, история файлов, восстановление системы, Storage Spaces). Особенности различных версий Windows 8.
курсовая работа , добавлен 25.01.2016
Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.
курсовая работа , добавлен 14.05.2014
Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.
реферат , добавлен 25.10.2010
Пакет средств разработки DirectX под Microsoft Windows, характеристика наборов COM-совместимых объектов в его составе. Ключевые особенности версий, шейдерные языки. Описание основных используемых функций. Исходный код программы, примеры ее работы.
курсовая работа , добавлен 16.02.2015
Windows как посредник пользователя и операционной системы, облегчая процесс общения между ними, история становления и развития ее первых версий. Функциональные особенности и отличия Windows 95/98/ME и Windows NT/2000/XP/Vista/7, их архитектурные решения.
презентация , добавлен 23.10.2013
Сокращение затрат на ремонтные работы по устранению дефектов, достигаемых при использовании информационной системы для их контроля. Анализ предметной области и программных средств. Расчет экономии за счет увеличения производительности труда пользователя.
дипломная работа , добавлен 19.01.2017
Понятие, сущность, структура и виды операционных систем. Характеристика операционной системы Windows XP, требования к ее установке, сравнительный анализ версий, особенности настройки, обновления версии, установки драйверов устройств и добавление новых.
реферат , добавлен 20.10.2009
Появление первых версий Windows, их графические интерфейсы и расширения для DOS. Семейства Windows 3.x и Windows 9.x, их особенности и основные функции. Эволюция технологии Plug and Play. Наиболее существенные улучшения в современных версиях Windows.
Перед тем, как говорить про какую либо конкретную систему контроля версий необходимо понимать, что это такое, какими они бывают и зачем вообще они появились. Эта лекция предназначена для первоначального знакомства с системами контроля и управления версиями, и сначала я расскажу о происхождении инструментов для контроля версий, расскажу, какие системы управления версиями сейчас популярны и в чем у них основные различия.
Наверное стоит начать с определения системы контроля версий (СКВ) - это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.
В последнее время файлы являются конечным результатом для многих профессий (для примера, писательскую деятельность, научные работы и, конечно, разработку программного обеспечения). Тратится много времени и сил на разработку и поддержку этих файлов и никто не хочет, чтобы пришлось тратить еще больше времени и сил на восстановление данных потерянных в результате каких-либо изменений.
Представим, что программист разрабатывает проект состоящий из одного небольшого файла (кстати, пример вполне реальный, не синтетический, встречался в реальной жизни). После выпуска первой версии проекта перед ним встает непростой выбор: необходимо исправлять проблемы о которых сообщают пользователи первой версии и, в тоже время, разрабатывать что-то новое для второй. Даже если надо просто исправлять возникающие проблемы, то велика вероятность, что после какого-либо изменения проект перестает работать, и надо определить, что было изменено, чтобы было проще локализовать проблему. Также желательно вести какой-то журнал внесенных изменений и исправлений, чтобы не делать несколько раз одну и ту же работу.
В простейшем случае вышеприведенную проблему можно решить хранением нескольких копий файлов, например, один для исправления ошибок в первой версии проекта и второй для новых изменений. Так как изменения обычно не очень большие по сравнению с размером файла, то можно хранить только измененные строки используя утилиту diff и позже объединять их с помощью утилиты patch. Но что если проект состоит из нескольких тысяч файлов и над ним работает сотня человек? Если в этом случае использовать метод с хранением отдельных копий файлов (или даже только изменений) то проект застопорится очень быстро. В последующих лекциях, для примеров я буду использовать исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.
Если вы графический или веб-дизайнер и хотели бы хранить каждую версию изображения или макета - а этого вам наверняка хочется - то пользоваться системой контроля версий будет очень мудрым решением. СКВ даёт возможность возвращать отдельные файлы к прежнему виду, возвращать к прежнему состоянию весь проект, просматривать происходящие со временем изменения, определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку, и многое другое. Вообще, если, пользуясь СКВ, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.
Как уже говорилось ранее - один из примеров локальной СУВ предельно прост: многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы. Чтобы решить эту проблему, программисты уже давно разработали локальные СКВ с простой базой данных, в которой хранятся все изменения нужных файлов
Одной из наиболее популярных СКВ такого типа является RCS (Revision Control System, Система контроля ревизий), которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. RCS была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy). Система позволяет хранить версии только одного файла, таким образом управлять несколькими файлами приходится вручную. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ",v". Например для файла file.txt версии будут храниться в файле file.txt,v. Эта утилита основана на работе с наборами патчей между парами версий (патч - файл, описывающий различие между файлами). Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи. Для хранения версий система использует утилиту diff. Хотя RCS соответствует минимальным требованиям к системе контроля версий она имеет следующие основные недостатки, которые также послужили стимулом для создания следующей рассматриваемой системы:
Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.
Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный - централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё - всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.
CVS (Concurrent Versions System, Система совместных версий) пока остается самой широко используемой системой, но быстро теряет свою популярность из-за недостатков которые я рассмотрю ниже. Дик Грун (Dick Grune) разработал CVS в середине 1980-х. Для хранения индивидуальных файлов CVS (также как и RCS) использует файлы в RCS формате, но позволяет управлять группами файлов расположенных в директориях. Также CVS использует клиент-сервер архитектуру в которой вся информация о версиях хранится на сервере. Использование клиент-сервер архитектуры позволяет использовать CVS даже географически распределенным командами пользователей где каждый пользователь имеет свой рабочий директорий с копией проекта. Как следует из названия пользователи могут использовать систему совместно.
Возможные конфликты при изменении одного и того же файла разрешаются тем, что система позволяет вносить изменения только в самую последнюю версию файла. Таким образом всегда рекомендуется перед заливкой своих изменений обновлять свою рабочую копию файлов на случай возможных конфликтующих изменений. При обновлении система вносит изменения в рабочую копию автоматически и только в случае конфликтующих изменений в одном из мест файла требуется ручное исправление места конфликта.
CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.
CVS использовалась большим количеством проектов, но конечно не была лишена недостатков которые позднее привели к появлению следующей рассматриваемой системы. Рассмотрим основные недостатки:
Subversion (SVN) был разработан в 2000 году по инициативе фирмы CollabNet. SVN изначально разрабатывался как "лучший CVS" и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру. Из наиболее значительных изменений по сравнению с CVS можно отметить:
И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.
Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.
Как следует из названия одна из основных идей распределенных систем - это отсутствие четко выделенного центрального хранилища версий - репозитория. В случае распределенных систем набор версий может быть полностью, или частично распределен между различными хранилищами, в том числе и удаленными. Такая модель отлично вписывается в работу распределенных команд, например, распределенной по всему миру команды разработчиков работающих над одним проектом с открытым исходным кодом. Разработчик такой команды может скачать себе всю информацию по версиям и после этого работать только на локальной машине. Как только будет достигнут результат одного из этапов работы, изменения могут быть залиты в один из центральных репозиториев или, опубликованы для просмотра на сайте разработчика, или в почтовой рассылке. Другие участники проекта, в свою очередь, смогут обновить свою копию хранилища версий новыми изменениями, или попробовать опубликованные изменения на отдельной, тестовой ветке разработки. К сожалению, без хорошей организации проекта отсутствие одного центрального хранилища может быть минусом распределенных систем. Если в случае централизованных систем всегда есть один общий репозиторий откуда можно получить последнюю версию проекта, то в случае распределенных систем нужно организационно решить какая из веток проекта будет основной. Почему распределенная система контроля версий может быть интересна кому-то, кто уже использует централизованную систему - такую как Subversion? Любая работа подразумевает принятие решений, и в большинстве случаев необходимо пробовать различные варианты: при работе с системами контроля версий для рассмотрения различных вариантов и работы над большими изменениями служат ветки разработки. И хотя это достаточно естественная концепция, пользоваться ей в Subversion достаточно не просто. Тем более, все усложняется в случае множественных последовательных объединений с одной ветки на другую - в этом случае нужно безошибочно указывать начальные и конечные версии каждого изменения, что бы избежать конфликтов и ошибок. Для распределенных систем контроля версий ветки разработки являются одной из основополагающих концепций - в большинстве случаев каждая копия хранилища версий является веткой разработки. Таким образом, механизм объединения изменений с одной ветки на другую в случае распределенных систем является одним из основных, что позволяет пользователям прикладывать меньше усилий при пользовании системой.
Краткое описание популярных распределенных СУВ
Системы контроля версиями записывают и сохраняют несколько изменений в файлах. Благодаря этому можно вернуться к определенной точке истории изменения файла или проекта. Некоторые системы, такие как Subversion , отслеживают историю отдельных файлов. Другие, такие как Git и Mercurial , отслеживают историю целых репозиториев.
Управление версиями подобно системе безопасности. Если вы внесли изменения, которые позже вызвали проблемы, можно будет вернуть файл или весь проект к определенной точке вместо того, чтобы начинать все с нуля.
Одним из наиболее часто используемых вариантов является локальное управление версиями. Поэтому большинство пользователей просто не обращают на него внимания, поскольку это одна из множества функций приложения.
В любом приложении реализован как минимум базовый уровень локального управления версиями, состоящий из функций «отменить» и «повторить ». Некоторые программы, такие как Microsoft Office и документы Google , содержат более сложные функции, такие как сравнение версий и комментирование.
Системы управления версиями в приложениях ограничены типами файлов, которые они поддерживают, и объемом истории изменений, которые они могут хранить. В свою очередь автономные системы управления версиями могут сосредоточиться на более сложных функциях, хранить бесконечные истории версий и не ограничиваться конкретными форматами. Хотя некоторые системы больше подходят для конкретных файлов. По этой причине они более популярны в программировании. Хотя они могут использоваться для управления версиями любого файла, от базовых текстовых документов до огромных графических файлов.
Системы контроля версий делятся на две категории: распределенные и централизованные. Каждая из них имеет свои преимущества и недостатки, которые делают их идеальными для различных рабочих процессов. К каждому типу относится множество различных систем. Наиболее популярными являются системы контроля версий Git, Subversion и Mercurial. Рассмотрим основные различия между распределенным и централизованным управлением версиями.
Распределенное управление версиями также известное как распределенное управление ревизиями. Оно построено по принципу равноправия узлов. Причем каждый равноправный узел имеет свой собственный клон репозитория. При подобном подходе копируется история базы кода, поэтому любое фатальное повреждение исходного, серверного репозитория может быть полностью восстановлено из любого из имеющихся клонов. Тем не менее, в стандартном рабочем процессе изменения в репозитории не приводят к полному обновлению репозитория. Вместо этого отображаются только внесенные изменения в равноправных узлах, что позволяет быстро выполнять операции без необходимости связываться с сервером.
Распределенное управление версиями является популярным благодаря таким системам, как Git и Mercurial . Они широко применяются для организации совместной работы в проектах с открытым исходным кодом. Из-за особенностей настройки клонирование всей базы кода проекта для каждой равноправной системы позволяет получить больше свободы, когда дело касается рабочих процессов и совместной работы.
В отличие от распределенной системы контроля версий и локального управления версиями, данные в централизованных системах управления версиями (CVC ), таких как Perforce и Subversion , хранятся в серверных хранилищах. Это означает, что каждый узел проверяет файлы и фиксирует изменения в центральной базе.
Проблема заключается в доступности данных. Поскольку файлы хранятся в центральном хранилище, если сервер дает сбой, никакая работа не сможет осуществляться до тех пор, пока сервер не будет перезапущен. Более того, если сервер будет поврежден, то при отсутствии актуальной резервной копии все данные могут быть полностью потеряны.
Главным преимуществом таких систем является то, что данные хранятся в одном месте. Это упрощает обслуживание и ограничивает доступ к ним со стороны пользователей.
Управление версиями — это удобный способ мониторинга изменений в файлах и проектах. Хотя системы контроля версий в первую очередь позиционируются как инструменты для управления проектами по разработке программного обеспечения, они могут оказаться полезными при управлении файлами любого типа.
Перевод статьи «What is version control » дружной командой проекта .
Хорошо Плохо
