NsmuBase

Учебные материалы и ответы на тесты

КУРСОВАЯ РАБОТА: Системы контроля версий

КУРСОВАЯ РАБОТА: Системы контроля версий

КУРСОВАЯ РАБОТА:

Системы контроля версий

СОДЕРЖАНИЕ
Введение
1. Системы контроля версий
1.1 Понятие системы контроля версий
1.2. Распределённые системы управления версиями
2. Виды систем контроля версий
2.1 Виды систем контроля версий
2.2 Система контроля версий CVS
2.3 Система контроля версий Subversion
2.4 Система контроля версий GIT
2.5 Система контроля версий Mercurial
2.6 Система контроля версий Bazaar
2.7 Система контроля версий Arch
2.8 Система контроля версий OpenCM
2.9 Система контроля версий Aegis
2.10 Система контроля версий Monotone
2.11 Система контроля версий BitKeeper
2.12 Система контроля версий Perforce
2.13 Система контроля версий Darcs
Заключение
Список использованных источников

ВВЕДЕНИЕ

Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. За время своего существования электронный документ может быть подвержен большому количеству изменений. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты. Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов. Вследствие этого были разработаны программные средства, которые упрощают данный механизм. Данные средства именуются системами контроля версий. Существует несколько такого рода систем, каждая из которых актуальна при определенных условиях их использования. Целью данного реферата является рассмотрение различного рода систем контроля версий.
В соответствии с поставленной целью необходимо решить следующие задачи:
 определить понятие системы контроля версий;
 проанализировать существующие системы контроля версий;
 рассмотреть основные виды данного рода систем из зарубежной и российской практики.
Задачи работы предопределили ее структуру. Реферат состоит из трех глав, введения, заключения, списка литературы и приложения. Теоретической базой работы являются научная, российская и зарубежная периодика и ресурсы сети Интернет.

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

1.1 Понятие система контроля версий

Система управления версиями (Version Control System или Revision Control System) представляют собой программное обеспечение для облегчения деятельности с быстро меняющейся информацией. Система контроля версий предоставляет возможность хранить несколько вариантов одного и того же документа. При необходимости можно вернуться к старым версиям, можно узнать, кем были сделаны те или иные изменения и т.д. Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. Система контроля версий позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием. Но тем не менее данные системы могут использоваться и в других областях знаний, которые включают в себя огромное количество часто изменяющихся электронных документов. Например, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления. Внутри репозитория могут быть несколько параллельных линий разработки, обычно называемых ветвями. Это может быть полезно для хранения стабильной или выпущенной версии ветви, одновременно продолжая работу над рабочей версией. Другой вариант – это открыть выделенную ветвь для работы над экпериментальной возможностью. Система контроля версий также позволяет пользователям дать ярлык снимку ветви (часто называемых как тэги) для легкого доставания. Это полезно для обозначения индивидуальных релизов или самых свежих рабочих версий, предназначенных для использования. Использование системы контроля версий безусловно обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков. Использование хорошей системы контроля версий определенно лучше, нежели использование узко-направленных специальных методов, которые используют некоторые разработчики для управления различными ревизиями своего кода.
Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, т. н. «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Сервер может использовать т. н. дельта-компрессию — такой способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.[1] Очень часто над одним и тем же проектом трудится несколько человек. Если один из них будет изменять исходный файл, и одновременно с этим другой человек будет выполнять аналогичную операцию, то возможна такая ситуация, что какие-то изменения могут не сохраниться. Системы контроля версий работают с такого рода проблемами и имеют определенный перечень их решения. В большинстве своем эти системы могут автоматически объединять такого рода изменения, которые делают разные члены команды разработчиков. Но стоит отметить, что такого рода объединения чаще всего выполняется для текстовых файлов и с определенным условием: изменения происходили в разных частях файла. Данное ограничение имеет место, поскольку в большинстве своем системы контроля версий направлены на поддержку процесса разработки программных продуктов, а изначальные коды находятся в текстовых файлах. В случае если автоматически выполнить объединение не получилось, то система предлагает исправить ситуацию вручную. Зачастую осуществить объединение не возможно ни с помощью системы, ни вручную. Ярким примером является ситуация когда формат файла очень сложный или неизвестен. Отдельные системы контроля версий предоставляют возможность пользователю заблокировать файл в хранилище. Данная операция не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом. [1] Многие системы управления версиями предоставляют ряд других возможностей:
 Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными — после неё.
 Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
 Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
 Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.[1]

1.2 Распределённые системы управления версиями

Существуют системы управления версиями, которые, вместо традиционной клиент-серверной, используют распределённую модель. Такие системы, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере. Фактически, каждый компьютер, помимо рабочей копии, хранит локальную копию всего хранилища. В некоторых системах рабочая копия сама является хранилищем. Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, копии, принадлежащие разным разработчикам, начинают различаться и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений между пользователями. Описанная модель аналогична созданию отдельной ветки для каждого разработчика в классической системе управления версиями (в некоторых распределённых системах перед началом работы с локальным хранилищем нужно создать новую ветвь). Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. Однако при необходимости выполнить слияние ветвей (или синхронизацию локальных хранилищ в распределённой модели) могут возникнуть конфликты. Основное преимущество распределённых систем заключается в их гибкости. Каждый разработчик может вести работу независимо, так, как ему удобно, сохраняя промежуточные варианты документов и передавая результаты другим участникам, когда посчитает нужным. При этом обмен наборами изменений может осуществляться по различным схемам. В небольших коллективах участники работы могут обмениваться изменениями по принципу «каждый с каждым», за счет чего отпадает необходимость в создании выделенного сервера. Крупное сообщество, наоборот, может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможны и более сложные варианты — например, с созданием групп для работы по отдельным направлениям внутри более крупного проекта. Распределенная система контроля версий позволяет клонировать удаленный репозиторий, производя точную копию. Она также позволяет распростанять изменения из одного репозитория на другой. В нераспределенных VCS разработчику нужен репозиторий для того, чтобы зафиксировать изменения в нем. Это делает разработчика без доступа к репозиторию человеком второго сорта. С распределенной VCS каждый разработчик может склонировать главный репозиторий, поработать над ним и потом распространить свои изменения на главный репозиторий.

2. Обзор систем контроля версий

2.1 Виды систем контроля версий

Система контроля версий может быть любой формы и размеров, но есть основные положения об их архитектуре. Некоторые системы поддерживают Атомарные Фиксации, которые значат, что состояние всего репозитория меняется полностью. Без Атомарных Фиксаций, каждый файл или часть меняется отдельно и поэтому состояние всего репозитория в любой точке не может быть зафиксировано. Большинство обычных VCS (Version Control System ) систем позволяют объединять изменения между ветвями. Это значит, что изменения, зафиксированные в одной ветви, будут зафиксированы в главной линии или в другой ветви с помощью одной автоматической или, по крайней мере, полуавтоматической операцией.

2.2 Система контроля версий CVS

Традиционно, де-факто системой контроля версий стала CVS (Система Параллельных Версий), но потом появилось много других, которые помогают лучше. Из всех этих возможностей CVS поддерживает только объединение изменений. Это зрелая и относительно надежная система контроля версий. Много проектов с открытыми исходными кодами, включая KDE, GNOME и Mozilla используют CVS. Большинство центров открытых исходных кодов, такие как SourceForge, предлагают CVS как сервис, поэтому ее используют во многих других проектах.
Система CVS имеет архитектуру клиент-сервер. Обычно сервер и клиент соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. Серверное ПО обычно работает под управлением Unix, тогда как CVS клиенты доступны во всех популярных операционных системах. (4) Сервер хранит в репозитории текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить нужную ему версию или записать новую. Получив с сервера нужную версию, клиент создаёт локальную копию проекта (или его части) — так называемую рабочую копию. После того как в файлы, находящиеся в рабочей копии, внесены необходимые изменения, они пересылаются на сервер.(4)
Пользователи имеют возможность сравнивать сравнить всевозможные версии файлов, просмотреть историю изменений или даже получить исторический образ проекта на определенную дату. Многие проекты формата «Открытых ресурсов» разрешают анонимный доступ на чтение. Данная возможность предполагает, что пользователи, могут получить доступ к версиям файлов без пароля. CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь, в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии. [4] Кроме того, стоит также отметить, что данная система использует механизм дельта-компрессии, чтобы более эффективно хранить разнообразные версии одного и того же файла.
Несмотря на свою популярность, CVS имеет ограничения. Например, она не поддерживает переименование файлов и директорий. Кроме того, бинарные файлы не обрабатываются достаточно хорошо. CVS – нераспределенная система и атомарные фиксации изменений не поддерживаются. Так как уже есть лучшие альтернативы, которые содержат более широкий набор функций, вы, возможно, предпочтете начать новый проект используя что-то другое. (2)
Как плюс, CVS очень хорошо документирована в своей книге и во многих онлайн руководствах. Также существуют множество графических клиентов и дополнений.

2.3 Система контроля версий Subversion

Subversion стремится быть лучшей альтернативой CVS (см. приложение 1). Она поддерживает большинство соглашений CVS, включая большую часть набора команд, поэтому пользователи CVS быстро чувствуют себя как дома. Subversion предлагает много полезных улучшений по сравнению с CVS: копирование и переименование файлов и директорий, настоящие атомарные фиксации, эффективная обработка бинарных файлов, способность сетевой работы по HTTP (и HTTPS ). Subversion также имеет Win32 клиент и сервер.
Таким образом, можно выделить следующие возможности Subversion:  Реализовано большинство возможностей CVS;
 Отслеживается история файлов, директорий и метаданных файлов, в том числе при переименовании и копировании;
 Публикации изменений атомарны;
 Возможность организации доступа к хранилищу Subversion через Apache по протоколу WebDAV/DeltaV;
 Возможность установки автономного сервера Subversion с доступом по собственному протоколу;
 «Дешёвые» операции создания ветвей и меток (требуется небольшое фиксированное количество временных и дисковых ресурсов);
 Многоуровневая архитектура библиотек, изначально рассчитанная на клиент-серверную модель;
 Клиент-серверный протокол пересылает по сети только разницу между объектами, когда это возможно;
 Затраты ресурсов пропорциональны размеру изменений, а не размеру данных, которые затронуты изменениями;
 Два возможных внутренних формата репозитория: база данных или простой файл;
 Версионированные символьные ссылки (только в рабочих копиях под UNIX-системами);
 Одинаково эффективная работа и с текстовыми, и с двоичными файлами;
 Вывод клиента командной строки одинаково удобен и для чтения, и для разбора программами;
 Частичная локализация сообщений (используются настройки локали);
 Библиотеки для языков PHP, Python, Perl, Java;
 Возможность зеркалирования репозитория. [5] Subversion недавно начала бета-период, после того как была долгое время в альфа-периоде. Поэтому, она еще может иметь небольшие причуды и ее производительность в некоторых местах невелика. И все-таки, она очень полезна для своего бета-периода и была такой даже в большей части своего альфа-периода. Сервис Subversion на основе HTTP (или HTTPS) труден для развертывания, по сравнению с другими системами, так как он требует установленной службы Apache2 со своим собственным специальным модулем. Также есть «svnserve » сервер, который менее способен, но более прост в установке и использует специальный протокол. Кроме того, поддержка Subversion объединения изменений ограничена и похожа в этом на CVS (т.е., объединение ветвей, где файлы были перемещены не будет выполнено корректно). Она также относительно требовательна к ресурсам, особенно на крупных операциях. [2] Subversion предлагает два варианта организации репозиториев. Репозитории первого типа используют для хранения базу данных на основе Berkeley DB, репозитории второго типа — в обычных файлах специального формата (доступ к данным организуется с помощью собственных библиотек, без использования сторонних баз данных). Оба типа репозиториев обеспечивают достаточную надежность при правильной организации, каждая из них обладает своими преимуществами и недостатками. Считается, что второй тип легче правильно настроить, она требует меньшего внимания от администратора.(5)
Subversion хорошо документирована в своей бесплатной онлайн книге, «Контроль Версий с Subversion». Небольшая онлайн система помощи, поставляемая с Subversion клиентом может также быть полезной в качестве справочника. Subversion имеет много дополнений, но они все еще менее зрелые, чем их CVS конкуренты.

2.4 Система управления версиями Git.

С февраля 2002 года для разработки ядра Linux’а большинством программистов стала использоваться система контроля версий BitKeeper. Довольно долгое время с ней не возникало проблем, но в 2005 году Лари МакВоем (разработчик BitKeeper’а) отозвал бесплатную версию программы.
Разрабатывать проект масштаба Linux без мощной и надежной системы контроля версий – невозможно. Одним из кандидатов и наиболее подходящим проектом оказалась система контроля версий Monotine, но Торвальдса Линуса не устроила ее скорость работы. Так как особенности организации Monatone не позволяли значительно увеличить скорость обработки данных, то 3 апреля 2005 года Линус приступил к разработке собственной системы контроля версий – Git.
Практически одновременно с Линусом (на три дня позже), к разработке новой системы контроля версий приступил и Мэтт Макал. Свой проект Мэтт назвал Mercurial, но об этом позже, а сейчас вернемся к распределенной системе контроля версий Git. Git – это гибкая, распределенная (без единого сервера) система контроля версий, дающая массу возможностей не только разработчикам программных продуктов, но и писателям для изменения, дополнения и отслеживания изменения «рукописей» и сюжетных линий, и учителям для корректировки и развития курса лекций, и администраторам для ведения документации, и для многих других направлений, требующих управления историей изменений. У каждого разработчика, использующего Git, есть свой локальный репозиторий, позволяющий локально управлять версиями. Затем, сохраненными в локальный репозиторий данными, можно обмениваться с другими пользователями. Часто при работе с Git создают центральный репозиторий, с которым остальные разработчики синхронизируются. Пример организации системы с центральным репозиторием – это проект разработки ядра Linux’a. В этом случае все участники проекта ведут свои локальны разработки и беспрепятственно скачивают обновления из центрального репозитория. Когда необходимые работы отдельными участниками проекта выполнены и отлажены, они, после удостоверения владельцем центрального репозитория в корректности и актуальности проделанной работы, загружают свои изменения в центральный репозиторий.
Наличие локальных репозиторием также значительно повышает надежность хранения данных, так как, если один из репозиториев выйдет из строя, данные могут быть легко восстановлены из других репозиториев.
Работа над версиями проекта в Git может вестись в нескольких ветках, которые затем могут с легкостью полностью или частично объединяться, уничтожаться, откатываться и разрастаться во все новые и новые ветки проекта. Можно долго обсуждать возможности Git’а, но для краткости и более простого восприятия приведем основные достоинства и недостатки этой системы управления версиями Достоинства:
 Надежная система сравнения ревизий и проверки корректности данных, основанные на алгоритме хеширования SHA1 (Secure Hash Algorithm 1).
 Гибкая система ветвления проектов и слияния веток между собой.
 Наличие локального репозитория, содержащего полную информацию обо всех изменениях, позволяет вести полноценный локальный контроль версий и заливать в главный репозиторий только полностью прошедшие проверку изменения.
 Высокая производительность и скорость работы.
 Удобный и интуитивно понятный набор команд.
 Множество графических оболочек, позволяющих быстро и качественно вести работы с Git’ом.
 Возможность делать контрольные точки, в которых данные сохраняются без дельта компрессии, а полностью. Это позволяет уменьшить скорость восстановления данных, так как за основу берется ближайшая контрольная точка, и восстановление идет от нее. Если бы контрольные точки отсутствовали, то восстановление больших проектов могло бы занимать часы.
 Широкая распространенность, легкая доступность и качественная документация.
 Гибкость системы позволяет удобно ее настраивать и даже создавать специализированные контроля системы или пользовательские интерфейсы на базе git.
 Универсальный сетевой доступ с использованием протоколов http, ftp, rsync, ssh и др.
Недостатки:
 Unix – ориентированность. На данный момент отсутствует зрелая реализация Git, совместимая с другими операционными системами.
 Возможные (но чрезвычайно низкие) совпадения хеш — кода отличных по содержанию ревизий.
 Не отслеживается изменение отдельных файлов, а только всего проекта целиком, что может быть неудобно при работе с большими проектами, содержащими множество несвязных файлов.
 При начальном (первом) создании репозитория и синхронизации его с другими разработчиками, потребуется достаточно длительное время для скачивания данных, особенно, если проект большой, так как требуется скопировать на локальный компьютер весь репозиторий. Выводы: Git – гибкая, удобная и мощная система контроля версий, способная удовлетворить абсолютное большинство пользователей. Существующие недостатки постепенно удаляются и не приносят серьезных проблем пользователям. Если вы ведете большой проект, территориально удаленный, и тем более, если часто приходится разрабатывать программное обеспечение, не имея доступа к другим разработчикам (например, вы не хотите терять время при перелете из страны в страну или во время поездки на работу), можно делать любые изменения и сохранять их в локальном репозитории, откатываться, переключаться между ветками и т.д.). Git – один из лидеров систем контроля версий.

2.5 Система управления версиями Mercurial.

Распределенная система контроля версий Mercurial разрабатывалась Мэттом Макалом параллельно с системой контроля версий Git, созданной Торвальдсом Линусом. Первоначально, она была создана для эффективного управления большими проектами под Linux’ом, а поэтому была ориентирована на быструю и надежную работу с большими репозиториями. На данный момент mercurial адаптирован для работы под Windows, Mac OS X и большинство Unix систем.
Большая часть системы контроля версий написана на языке Python, и только отдельные участки программы, требующие наибольшего быстродействия, написаны на языке Си. Идентификация ревизий происходит на основе алгоритма хеширования SHA1 (Secure Hash Algorithm 1), однако, также предусмотрена возможность присвоения ревизиям индивидуальных номеров. Так же, как и в git’е, поддерживается возможность создания веток проекта с последующим их слиянием.
Для взаимодействия между клиентами используются протоколы HTTP, HTTPS или SSH. Набор команд — простой и интуитивно понятный, во многом схожий с командами subversion. Так же имеется ряд графических оболочек и доступ к репозиторию через веб-интерфейс. Немаловажным является и наличие утилит, позволяющих импортировать репозитории многих других систем контроля версий. Рассмотрим основные достоинства и недостатки Mercurial.
Достоинства:
 Быстрая обработка данных.
 Кросплатформенная поддержка.
 Возможность работы с несколькими ветками проекта.
 Простота в обращение.
 Возможность конвертирования репозиториев других систем поддержки версий, таких как CVS, Subversion, Git, Darcs, GNU Arch, Bazaar и др.
Недостатки:
Возможные (но чрезвычайно низкие) совпадения хеш — кода отличных по содержанию ревизий.
Ориентирован на работу в консоли.
Выводы:
Простой и отточенный интерфейс, и набор команд, возможность импортировать репозитории с других систем контроля версий, — сделают переход на Mercurial и обучение основным особенностями безболезненным и быстрым. Вряд ли это займет больше нескольких дней.
Надежность и скорость работы позволяют использовать его для контроля версий огромных проектов. Все это делает mercurial достойным конкурентом git’а.

2.6 Система управления версиями Bazaar.

Bazaar – распределенная, свободно распространяемая система контроля версий, разрабатываемая при поддержке компании Canonical Ltd. Написана на языке Python и работает под управлением операционных систем Linux, Mac OS X и Windows. В отличие от Git и Mercurial, создаваемых для контроля версий ядра операционной системы Linux, а поэтому ориентированных на максимальное быстродействие при работе с огромным числом файлов, Bazaar ориентировался на удобный и дружественный интерфейс пользователя. Оптимизация скорости работы производилось уже на втором этапе, когда первые версии программы уже появились. Как и во многих других системах контроля версий, система команд Bazaar’a — очень похожа на команды CVS или Subversion, что, впрочем, неудивительно, так как обеспечивает удобный, простой и интуитивно понятный интерфейс взаимодействия с программой. Приятно, что огромное внимание уделяется работе с ветками проектов (создание, объединение веток и т.д.), что очень важно при разработке серьезных проектов и позволяет проводить доработки и эксперименты без угрозы потери основной версии программного обеспечения. Большой плюс этой системе контроля версий дает возможность работы с репозиториями других систем контроля версий, таких как Subversion или Git. Кратко приведем наиболее значительные достоинства и недостатки этой системы контроля версий.
Достоинства:
 Кросплатформенная поддержка.
 Удобный и интуитивно понятный интерфейс.
 Простая работа с ветками проекта.
 Возможность работы с репозиториями других систем контроля версий.
 Великолепная документация.
 Удобный графический интерфейс.
 Чрезвычайная гибкость, позволяющая подстроится под нужды конкретного пользователя. Недостатки:
Более низкая скорость работы, по сравнению с git и mercurial, но эта ситуация постепенно исправляется. Для полноценного функционирования необходимо устанавливать достаточно большое количество плагинов, позволяющих полностью раскрыть все возможности системы контроля версий. Выводы:
Bazaar – удобная система контроля версий с приятным интерфейсом. Хорошо подходит для пользователей, которых отталкивает перспектива работы с командной строкой. Множество дополнительных опций и расширений позволит настроить программу под свои нужды. Схожесть системы команд с Git и Subversion, и возможность работы напрямую с их репозиториями, — сделает переход на Bazaar быстрым и безболезненным. Об успешности базара говорит и тот факт, что ей пользуются разработчики Ubuntu Linux.

2.7 Система контроля версий Arch

GNU Arch – это VCS, первоначально созданная Томом Лордом ( Tom Lord ) для своих нужд. Изначально Arch была коллекцией shell-скриптов, но сейчас ее основной клиент это tla, который написан на C и должен переноситься на любую UNIX-систему. Он не был портирован на Win32; хотя это и возможно сделать, это не приоритет для проекта. (2) Arch – распределенная система контроля версий. Она не требует специального сервиса для установки сетевого репозитория и подходит любой удаленный файловый сервис (такие как FTP, SFTP или WebDAV). Это делает установку сервиса невероятно легкой. Arch поддерживает версионные переименования файлов и директорий, а также интеллектуальное объединение, которое может определить, был ли файл переименован и затем чисто применяет изменения. Arch стремится быть лучше CVS, но все еще есть некоторые пропущенные возможности. Версия Arch перешагнула 1.0 порог и потому объявлена зрелым и надежным продуктом для любого использования.
Arch документирована очень простой онлайн системой помощи и руководства.

2.8 Система контроля версий OpenCM

OpenCM — система контроля версий, созданная для проекта EROS. OpenCM не стремится быть богатой возможностями как CVS, но она имеет несколько преимуществ. OpenCM имеет версионные переименования файлов и директорий, атомарные фиксации, автоматическое распространение изменений от ветви в главную ветвь и некоторую поддержку криптографической аутентификации. Рассмотрим список главных особенностей OpenCM:
 Данная система предназначена для реальной конфигурации. Это то удивительно, что не знает CVS;
 Способность переименовывать файлы, не теряя их истории;
 Управления доступом к истории по ветвям;
 Шифровальное установление подлинности. Это обеспечивает способность сделать отчеты разработчиков на репозитории OpenCM, не давая им отчет на основной машине (OS), и делает сотрудничество мульти-организаций возможным.
 Непрерывные средства управления за целостностью. Если у сервера есть плохой файл, или сервер мультиплицирования активно пытается заменить надлежащее содержание, конечный пользователь может обнаружить ошибку или замену. (6) OpenCM использует свой собственный протокол для связи мужду клиентом и сервером. Система не является распределенной. Так как OpenCM не отличается богатством возможностей, возможно, что другие системы вам подойдут больше. Однако вы можете предпочесть OpenCM, если какая-то отличительная возможность этой системы вам понравится. OpenCM работает под любой UNIX -системой и на Windows под эмуляцией Cygwin. Она имеет CVS -подобные команды и хорошо документирована.

2.9 Система контроля версий Aegis

Aegis – система управления конфигурацией кода созданная Питером Миллером ( Peter Miller ). Она не сетевая и все операции делаются через файловую систему UNIX. По существу, она использует систему разрешений UNIX для определения, кто имеет доступ для выполнения какой операции. Несмотря на тот факт, что Aegis не сетевая, она все же распределенная в том смысле, что репозитории могут быть клонированы и изменения могут быть распространены с одного репозитория на другой. Использование по сети требует сетевой операционной системы, такой как NFS. Будучи SCM системой, Aegis пытается обеспечить корректность кода, который был внесен. То есть, она:
 Управляет автоматизированными тестами, предотвращает внесения, которые не проходят предыдущие тесты и требует разработчиков добавить новые тесты.
 Управляет обзорами кода. Внесения должны пройти обзор обозревателя, чтобы попасть в главную линию разработки.
 Имеет различные другие возможности, которые помогают гарантировать качество кода.
 Ее набор команд отражает эту философию и является очень нудным, если вам нужна просто система контроля версий. Aegis документирована в нескольких troff документах, которые были преобразованы в PostScript. Иногда бывает трудно просмотреть документацию, чтобы найти точно то, что вам нужно. Однако документация высокого качества.

2.10 Система контроля версий Monotone

Система контроля версий Monotone была создана Грейдоном Хоэм ( Graydon Hoare ) и показывает различную философию, чем все системы, приведенные выше. Она распределенная, с наборами изменений, распространяемыми через определенное хранилище, которое может быть CGI скрипт, NNTP (новости Usenet ) получатель или SMTP ( email ). Оттуда, каждый разработчик помещает желаемые изменения в свою собственную копию репозитория. Это может иметь печальный эффект потери синхронизации истории изменений или текущего состояния индивидуальных репозиториев друг с другом, так как индивидуальные репозитории не получают соответствующие изменения или получают несоответствующие. Monotone очень зависит от сильного шифрования. Она идентифицирует файлы, директории и ревизии контрольными суммами SHA 1. Monotone поддерживает переименования и копии файлов и директорий. Она имеет набор команд, который стремится быть CVS -совместимым, с некоторыми необходимыми отступлениями, из-за своей различной философии. Она должна быть переносима на Win32, но официально перенос еще не был выполнен.
Monotone все еще в разработке и может все еще иметь некоторые проблемы в поведении. Разработчики Monotone ожидают, что проблемы разрешатся, так как работа продолжается.
В общем, Monotone содержит много из обещанного.

2.11 Система контроля версий BitKeeper

BitKeeper- не является системой контроля версий с открытыми кодами, но рассмотрена здесь для полноты картины, потому что некоторые проекты с открытыми кодами используют ее. BitKeeper очень надежна и богата возможностями, поддерживая распределенные репозитории; работая по HTTP; поддерживая переименование и копирование файлов и директорий; управление патчами; распространяя изменения от ветви в главную линию и много других возможностей. BitKeeper распространяется с двумя лицензиями. Коммерческая лицензия стоит несколько сот долларов на место (лизинг или покупка). Бесплатная лицензия доступна для разработки ПО с открытыми кодами, но имеет некоторые ограничения, среди которых – условие о неконкуренции (создаваемый продукт не может быть конкурентным по отношению к данному) и требование об обновлении системы при появлении более свежей версии, даже если она имеет другую лицензию. Кроме того, исходный код не доступен публично и бинарники существуют только для самых распространенных систем, включая Win 32.
Преимущества BitKeeper:
 Высокая производительность: BitKeeper была разработана, чтобы упростить исходные задачи управления и обеспечить превосходную инфраструктуру для отладки и рассмотрения кода.
 Снижена вероятность человеческой ошибки: BitKeeper осуществляет проверки целостности репозитория, которые немедленно улавливают проблемы.
 Воспроизводимость: Комплексы проектов программного обеспечения с множеством разработчиков требуют инструментов управления конфигурации программного обеспечения, которые учитывают точную воспроизводимость прошлой и настоящей информации. Поскольку BitKeeper поддерживает понятие логической единицы работы, где каждая единица является неизменной — не может измениться, но может быть добавлено — BitKeeper производит полностью восстанавливаемый репозиторий в любой момент времени. BitKeeper управляет процессом развития так, чтобы каждая фаза проекта может быть обновлена в будущем.
 Ответственность: Поскольку репозитории полностью восстанавливаемы в любой момент времени, легко узнать, кто сделал, какие изменения, и что другие файлы были изменены в то же самое время. Отладка становится намного более эффективным с BitKeeper.
 Разъединенные/Распределенные операции: Рабочее пространство каждого пользователя содержит историю пересмотра файлов таким образом, чтобы вся работа могла возобновить без любого взаимодействия с главным репозиторием, таким образом это не потребность, чтобы иметь связь TCP между всеми системами все время.
 Масштабируемость: Архитектура BitKeeper’s неотъемлемо масштабируема, так, что одинаково хорошо работает и для пяти разработчиков, и для 1 000 или 10 000. (8) Горстка проектов используют BitKeeper, включая некоторых из разработчиков Linux ядра и основная команда разработчиков MySQL. Из-за ее лицензии BitKeeper не удобен для разработки ПО с открытым кодом, так как оно заставит отвернуться многих «идеалистических» разработчиков и создаст различные проблемы для пользователей, кто выберет ее для использования. Если вы работаете над непубличным проектом и можете позволить себе заплатить за BitKeeper, это естественный вариант.

2.12 Система контроля версий Perforce

Данная коммерческая система управления версиями разработана компанией Perforce Software. В основе нее лежит клиент-серверная архитектура. Сервер данной системы может одновременно иметь несколько репозиториев. Сервер Perforce может быть установлен на операционные системы Unix, Mac OS X, Microsoft Windows. Клиент предоставляет графический интерфейс и широкий набор утилит для работы из командной строки. Клиентская часть реализована для широкого набора операционных систем. Также разработан большой набор плагинов, позволяющих интегрироваться с широким кругом сред разработки программного обеспечения и приложений других разработчиков: IntelliJ IDEA, XCode, Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs. Помимо этого система предоставляет множество других возможностей — различного вида извещения, создание и обслуживание ветвей проекта, с мощной системой слияний веток, точки отката в базе данных, и взаимодействие с системами отслеживания дефектов. (9) В настоящее время такие компании как Google и Microsoft, широко используют Perforce в своих инженерных процессах.
Основные недостатки данной системы:
 высокая цена лицензии на сервер;
 распространяется в бинарном виде. (1)
2.13 Система контроля версий Darcs Данная система контроля версий является распределенной, подобно Arch и Monotone.
Dars имеет несколько весьма полезных особенностей:  Офлайн-режим. Вы можете подтверждать изменения, даже если вы не имеете доступа к серверу. Это работает, поскольку директория вашего проекта, управляемая Darcs является полноценным репозиторием, все изменения сохраняются в нём. Вы приезжаете домой или на работу, подключаете ноутбук к сети и просто переносите все ранее сделанные изменения с помощью «darcs push» на публично доступный сервер.
 Простота ветвления. В Dars каждый репозиторий фактически является отдельной веткой. Работаете над новой функцией, но потребовалось срочно исправить ошибку? Тогда публикуете изменения относящиеся к багфиксу, подтверждаете изменения и продолжаете работу над своей новой функцией — ваш репозиторий будет веткой основной разработки.
 Режим Линуса. Например, вы хотите добавить новую функцию или исправить ошибку в open-source проекте. Вы делаете локальную копию репозитория в Darcs, производите нужные изменения и отправляете патчи по электронной почте. Майнтейнер проекта решает принять или отклонить изменения. Таким образом, вам не требуется непосредственного доступа на запись в репозиторий проекта. Таким образом поддерживается сам проект Darcs, подобным же путём Линусом Торвальдсом ведётся (велась ранее?) разработка ядра Linux.
 Параллельная разработка. Новая ветка разработки ведётся параллельно с основной и при необходимости может быть объединена с ней в любое время. Таким образом, легко разделить разработку, но в то же время легко объединять параллельно ведомые разработки, интегрируя наработки независимых разработчиков — «форк» перестаёт быть тем злом, которым его пытаются представить представители проприетарного программного обеспечения.
 Простота ведения версий файлов конфигурации. Централизованное ведение общей конфигурации на любом числе машин становится простым делом, не только потому, что Darcs поддерживает перенос изменений, вы можете настроить Darcs, чтобы он делал этот перенос на все машины сразу одной командой.
 Cherry-picking («Собираем сливки»). Даже работая в команде, может сложиться ситуация, когда кто-то имеет полезные изменения, которые вам нужны, но пока не имеет возможности их опубликовать в основную ветку. С Darcs вы можете забрать к себе только те изменения в репозитории, которые вам нужны в данный момент. [10]

ЗАКЛЮЧЕНИЕ

В работе были рассмотрены системы контроля версий, проведен краткий сравнительный анализ систем.
Такого рода системы позволяют облегчить проекты по разработки программного обеспечения, и в определенной степени исключить человеческие ошибки. Существующие системы мониторинга помогут в случае возникновения каких-либо нестыковок в работе. В настоящее время существует большое количество систем контроля версий, и наиболее интересные и информативные варианты представлены в работе. Пока не существует идеальных систем, каждая из них обладает определенными недостатками, но одновременно с этим и рядом особенностей, которые выделяют ее. На смену относительно старым системам (CVS) приходят улучшенные альтернативы. Другие системы более приятны и предоставляют лучший рабочий опыт. У потребителя, безусловно, есть много возможностей для выбора. Большинство производителей предлагают демонстрационные версии своих программных продуктов.
Системы контроля версий являются потрясающим решение проблем распространенных корпораций. Безусловно данная область будет развиваться и в дальнейшем возможно увеличение числа систем и существенная доработка существующих.

 

КУРСОВАЯ РАБОТА: Системы контроля версий

Next Post

Previous Post

© 2020 NsmuBase

Проект winterweb.pro