Системы контроля версий
Понятие системы контроля версий. Возможность хранить несколько вариантов одного и того же документа. Централизованная модель и единое хранилище документов. Основные виды систем контроля версий. Характеристики Subversion, Arch, OpenCM, Aegis, Monotone.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 13.12.2012 |
| Размер файла | 41,9 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ВЫСШАЯ ШКОЛА ЭКОНОМИКИ
ПЕРМСКИЙ ФИЛИАЛ
Факультет бизнес-информатики
Отделение программной инженерии
реферат
на тему системы контроля версий
Студентки группы 171мУРПО
Пермяковой Е.А.
Преподаватель:
Авдошин С. М.
Москва 2008
Содержание
- Введение
- 1. Понятие системы контроля версий
- 1.1 Распределённые системы управления версиями
- 2. Виды систем контроля версий
- 2.1 CVS
- 2.2 Subversion
- 2.3 Arch
- 2.4 OpenCM
- 2.5 Aegis
- 2.6 Monotone
- 2.7 BitKeeper
- 2.8 Perforce
- 2.9 Darcs
- Заключение
- Список литературы.
- Приложение 1.
- Приложение 2.
- Введение
- Сегодня в мире, где существует огромное количество сложных систем, существует необходимость видоизменения электронных документов на различных стадиях их разработки. За время своего существования электронный документ может быть подвержен большому количеству изменений. Однако часто так бывает, что для дальнейшей работы необходима не только последняя версия документа, но и различные предыдущие варианты.
- Безусловно, можно хранить несколько различных вариантов необходимого документа, но данный способ неэффективен. Нам приходится тратить кучу времени и сил, необходимо особое внимание и велика вероятность ошибки. Кроме того нам приходится хранить огромное количество практически идентичных документов.
- Вследствие этого были разработаны программные средства, которые упрощают данный механизм. Данные средства именуются системами контроля версий. Существует несколько такого рода систем, каждая из которых актуальна при определенных условиях их использования.
- Целью данного реферата является рассмотрение различного рода систем контроля версий.
- В соответствии с поставленной целью необходимо решить следующие задачи:
- o определить понятие системы контроля версий;
- o проанализировать существующие системы контроля версий;
- o рассмотреть основные виды данного рода систем из зарубежной и российской практики.
- Задачи работы предопределили ее структуру. Реферат состоит из трех глав, введения, заключения, списка литературы и приложения.
- Теоретической базой работы являются научная, российская и зарубежная периодика и ресурсы сети Интернет.
1. Понятие системы контроля версий
Система управления версиями (Version Control System или Revision Control System) представляют собой программное обеспечение для облегчения деятельности с быстро меняющейся информацией. Система контроля версий предоставляет возможность хранить несколько вариантов одного и того же документа. При необходимости можно вернуться к старым версиям, можно узнать, кем были сделаны те или иные изменения и т.д.
Такого рода системы в большинстве своем используются при разработке программного обеспечения, чтобы можно было хранить исходные коды разрабатываемых программ. Система контроля версий позволяет разработчикам хранить прошлые версии файлов из разработки и доставать их оттуда. Она хранит информацию о версии каждого файла (и полную структуру проекта) в коллекции, обычно называемой репозиторием. Но тем не менее данные системы могут использоваться и в других областях знаний, которые включают в себя огромное количество часто изменяющихся электронных документов. Например, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления.
Внутри репозитория могут быть несколько параллельных линий разработки, обычно называемых ветвями. Это может быть полезно для хранения стабильной или выпущенной версии ветви, одновременно продолжая работу над рабочей версией. Другой вариант - это открыть выделенную ветвь для работы над экпериментальной возможностью.
Система контроля версий также позволяет пользователям дать ярлык снимку ветви (часто называемых как тэги) для легкого доставания. Это полезно для обозначения индивидуальных релизов или самых свежих рабочих версий, предназначенных для использования.
Использование системы контроля версий безусловно обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков. Использование хорошей системы контроля версий определенно лучше, нежели использование узко-направленных специальных методов, которые используют некоторые разработчики для управления различными ревизиями своего кода.
Большинство систем управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет большую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, т. н. «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Сервер может использовать т. н. дельта-компрессию - такой способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.[1]
Очень часто над одним и тем же проектом трудится несколько человек. Если один из них будет изменять исходный файл, и одновременно с этим другой человек будет выполнять аналогичную операцию, то возможна такая ситуация, что какие-то изменения могут не сохраниться. Системы контроля версий работают с такого рода проблемами и имеют определенный перечень их решения. В большинстве своем эти системы могут автоматически объединять такого рода изменения, которые делают разные члены команды разработчиков. Но стоит отметить, что такого рода объединения чаще всего выполняется для текстовых файлов и с определенным условием: изменения происходили в разных частях файла. Данное ограничение имеет место, поскольку в большинстве своем системы контроля версий направлены на поддержку процесса разработки программных продуктов, а изначальные коды находятся в текстовых файлах. В случае если автоматически выполнить объединение не получилось, то система предлагает исправить ситуацию вручную.
Зачастую осуществить объединение не возможно ни с помощью системы, ни вручную. Ярким примером является ситуация когда формат файла очень сложный или неизвестен. Отдельные системы контроля версий предоставляют возможность пользователю заблокировать файл в хранилище. Данная операция не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом. [1]
Многие системы управления версиями предоставляют ряд других возможностей:
Ш Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными -- после неё.
Ш Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
Ш Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
Ш Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.[1]
1.1 Распределённые системы управления версиями
Существуют системы управления версиями, которые, вместо традиционной клиент-серверной, используют распределённую модель. Такие системы, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере. Фактически, каждый компьютер, помимо рабочей копии, хранит локальную копию всего хранилища. В некоторых системах рабочая копия сама является хранилищем.
Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, копии, принадлежащие разным разработчикам, начинают различаться и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений между пользователями.
Описанная модель аналогична созданию отдельной ветки для каждого разработчика в классической системе управления версиями (в некоторых распределённых системах перед началом работы с локальным хранилищем нужно создать новую ветвь). Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. Однако при необходимости выполнить слияние ветвей (или синхронизацию локальных хранилищ в распределённой модели) могут возникнуть конфликты.
Основное преимущество распределённых систем заключается в их гибкости. Каждый разработчик может вести работу независимо, так, как ему удобно, сохраняя промежуточные варианты документов и передавая результаты другим участникам, когда посчитает нужным. При этом обмен наборами изменений может осуществляться по различным схемам. В небольших коллективах участники работы могут обмениваться изменениями по принципу «каждый с каждым», за счет чего отпадает необходимость в создании выделенного сервера. Крупное сообщество, наоборот, может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможны и более сложные варианты - например, с созданием групп для работы по отдельным направлениям внутри более крупного проекта.
Распределенная система контроля версий позволяет клонировать удаленный репозиторий, производя точную копию. Она также позволяет распростанять изменения из одного репозитория на другой. В нераспределенных VCS разработчику нужен репозиторий для того, чтобы зафиксировать изменения в нем. Это делает разработчика без доступа к репозиторию человеком второго сорта. С распределенной VCS каждый разработчик может склонировать главный репозиторий, поработать над ним и потом распространить свои изменения на главный репозиторий.
2. Виды систем контроля версий
Система контроля версий может быть любой формы и размеров, но есть основные положения об их архитектуре. Некоторые системы поддерживают Атомарные Фиксации, которые значат, что состояние всего репозитория меняется полностью. Без Атомарных Фиксаций, каждый файл или часть меняется отдельно и поэтому состояние всего репозитория в любой точке не может быть зафиксировано.
Большинство обычных VCS (Version Control System ) систем позволяют объединять изменения между ветвями. Это значит, что изменения, зафиксированные в одной ветви, будут зафиксированы в главной линии или в другой ветви с помощью одной автоматической или, по крайней мере, полуавтоматической операцией.
2.1 CVS
Традиционно, де-факто системой контроля версий стала CVS (Система Параллельных Версий), но потом появилось много других, которые помогают лучше. Из всех этих возможностей CVS поддерживает только объединение изменений.
Это зрелая и относительно надежная система контроля версий. Много проектов с открытыми исходными кодами, включая KDE, GNOME и Mozilla используют CVS. Большинство центров открытых исходных кодов, такие как SourceForge, предлагают CVS как сервис, поэтому ее используют во многих других проектах.
Система CVS имеет архитектуру клиент-сервер. Обычно сервер и клиент соединяются через локальную сеть или через Интернет, но могут работать и на одной машине, если необходимо вести историю версий локального проекта. Серверное ПО обычно работает под управлением Unix, тогда как CVS клиенты доступны во всех популярных операционных системах. (4)
Сервер хранит в репозитории текущую версию (версии) проекта и историю изменений, а клиент соединяется с ним, чтобы получить нужную ему версию или записать новую. Получив с сервера нужную версию, клиент создаёт локальную копию проекта (или его части) -- так называемую рабочую копию. После того как в файлы, находящиеся в рабочей копии, внесены необходимые изменения, они пересылаются на сервер.(4)
Пользователи имеют возможность сравнивать сравнить всевозможные версии файлов, просмотреть историю изменений или даже получить исторический образ проекта на определенную дату. Многие проекты формата «Открытых ресурсов» разрешают анонимный доступ на чтение. Данная возможность предполагает, что пользователи, могут получить доступ к версиям файлов без пароля.
CVS также может содержать различные ветки проекта. Например, стабильная версия проекта может составлять одну ветвь, в которую вносятся только исправления ошибок, тогда как активная разработка может вестись в параллельной ветке, которая включает значительные улучшения или изменения с момента выхода стабильной версии. [4]
Кроме того, стоит также отметить, что данная система использует механизм дельта-компрессии, чтобы более эффективно хранить разнообразные версии одного и того же файла.
Несмотря на свою популярность, CVS имеет ограничения. Например, она не поддерживает переименование файлов и директорий. Кроме того, бинарные файлы не обрабатываются достаточно хорошо. CVS - нераспределенная система и атомарные фиксации изменений не поддерживаются. Так как уже есть лучшие альтернативы, которые содержат более широкий набор функций, вы, возможно, предпочтете начать новый проект используя что-то другое. (2)
Как плюс, CVS очень хорошо документирована в своей книге и во многих онлайн руководствах. Также существуют множество графических клиентов и дополнений.
2.2 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.3 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.4 OpenCM
OpenCM - система контроля версий, созданная для проекта EROS. OpenCM не стремится быть богатой возможностями как CVS , но она имеет несколько преимуществ. OpenCM имеет версионные переименования файлов и директорий, атомарные фиксации, автоматическое распространение изменений от ветви в главную ветвь и некоторую поддержку криптографической аутентификации.
Рассмотрим список главных особенностей OpenCM:
· Данная система предназначена для реальной конфигурации. Это то удивительно, что не знает CVS;
· Способность переименовывать файлы, не теряя их истории;
· Управления доступом к истории по ветвям;
· Шифровальное установление подлинности. Это обеспечивает способность сделать отчеты разработчиков на репозитории OpenCM, не давая им отчет на основной машине (OS), и делает сотрудничество мульти-организаций возможным.
· Непрерывные средства управления за целостностью. Если у сервера есть плохой файл, или сервер мультиплицирования активно пытается заменить надлежащее содержание, конечный пользователь может обнаружить ошибку или замену. (6)
OpenCM использует свой собственный протокол для связи мужду клиентом и сервером. Система не является распределенной. Так как OpenCM не отличается богатством возможностей, возможно, что другие системы вам подойдут больше. Однако вы можете предпочесть OpenCM, если какая-то отличительная возможность этой системы вам понравится.
OpenCM работает под любой UNIX -системой и на Windows под эмуляцией Cygwin . Она имеет CVS -подобные команды и хорошо документирована.
2.5 Aegis
Aegis - система управления конфигурацией кода созданная Питером Миллером ( Peter Miller ). Она не сетевая и все операции делаются через файловую систему UNIX . По существу, она использует систему разрешений UNIX для определения, кто имеет доступ для выполнения какой операции. Несмотря на тот факт, что Aegis не сетевая, она все же распределенная в том смысле, что репозитории могут быть клонированы и изменения могут быть распространены с одного репозитория на другой. Использование по сети требует сетевой операционной системы, такой как NFS .
Будучи SCM системой, Aegis пытается обеспечить корректность кода, который был внесен. То есть, она:
· Управляет автоматизированными тестами, предотвращает внесения, которые не проходят предыдущие тесты и требует разработчиков добавить новые тесты.
· Управляет обзорами кода. Внесения должны пройти обзор обозревателя, чтобы попасть в главную линию разработки.
· Имеет различные другие возможности, которые помогают гарантировать качество кода.
· Ее набор команд отражает эту философию и является очень нудным, если вам нужна просто система контроля версий.
Aegis документирована в нескольких troff документах, которые были преобразованы в PostScript . Иногда бывает трудно просмотреть документацию, чтобы найти точно то, что вам нужно. Однако документация высокого качества.
2.6 Monotone
Система контроля версий Monotone была создана Грейдоном Хоэм ( Graydon Hoare ) и показывает различную философию, чем все системы, приведенные выше. Она распределенная, с наборами изменений, распространяемыми через определенное хранилище, которое может быть CGI скрипт, NNTP (новости Usenet ) получатель или SMTP ( email ). Оттуда, каждый разработчик помещает желаемые изменения в свою собственную копию репозитория.
Это может иметь печальный эффект потери синхронизации истории изменений или текущего состояния индивидуальных репозиториев друг с другом, так как индивидуальные репозитории не получают соответствующие изменения или получают несоответствующие.
Monotone очень зависит от сильного шифрования. Она идентифицирует файлы, директории и ревизии контрольными суммами SHA 1.
Monotone поддерживает переименования и копии файлов и директорий. Она имеет набор команд, который стремится быть CVS -совместимым, с некоторыми необходимыми отступлениями, из-за своей различной философии. Она должна быть переносима на Win32, но официально перенос еще не был выполнен.
Monotone все еще в разработке и может все еще иметь некоторые проблемы в поведении. Разработчики Monotone ожидают, что проблемы разрешатся, так как работа продолжается.
В общем, Monotone содержит много из обещанного.
2.7 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.8 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.9 Darcs
Данная система контроля версий является распределенной, подобно Arch и Monotone.
Dars имеет несколько весьма полезных особенностей:
· Офлайн-режим. Вы можете подтверждать изменения, даже если вы не имеете доступа к серверу. Это работает, поскольку директория вашего проекта, управляемая Darcs является полноценным репозиторием, все изменения сохраняются в нём. Вы приезжаете домой или на работу, подключаете ноутбук к сети и просто переносите все ранее сделанные изменения с помощью "darcs push" на публично доступный сервер.
· Простота ветвления. В Dars каждый репозиторий фактически является отдельной веткой. Работаете над новой функцией, но потребовалось срочно исправить ошибку? Тогда публикуете изменения относящиеся к багфиксу, подтверждаете изменения и продолжаете работу над своей новой функцией - ваш репозиторий будет веткой основной разработки.
· Режим Линуса. Например, вы хотите добавить новую функцию или исправить ошибку в open-source проекте. Вы делаете локальную копию репозитория в Darcs, производите нужные изменения и отправляете патчи по электронной почте. Майнтейнер проекта решает принять или отклонить изменения. Таким образом, вам не требуется непосредственного доступа на запись в репозиторий проекта. Таким образом поддерживается сам проект Darcs, подобным же путём Линусом Торвальдсом ведётся (велась ранее?) разработка ядра Linux.
· Параллельная разработка. Новая ветка разработки ведётся параллельно с основной и при необходимости может быть объединена с ней в любое время. Таким образом, легко разделить разработку, но в то же время легко объединять параллельно ведомые разработки, интегрируя наработки независимых разработчиков - "форк" перестаёт быть тем злом, которым его пытаются представить представители проприетарного программного обеспечения.
· Простота ведения версий файлов конфигурации. Централизованное ведение общей конфигурации на любом числе машин становится простым делом, не только потому, что Darcs поддерживает перенос изменений, вы можете настроить Darcs, чтобы он делал этот перенос на все машины сразу одной командой.
· Cherry-picking ("Собираем сливки"). Даже работая в команде, может сложиться ситуация, когда кто-то имеет полезные изменения, которые вам нужны, но пока не имеет возможности их опубликовать в основную ветку. С Darcs вы можете забрать к себе только те изменения в репозитории, которые вам нужны в данный момент. [10]
Заключение
В работе были рассмотрены системы контроля версий, проведен краткий сравнительный анализ систем.
Такого рода системы позволяют облегчить проекты по разработки программного обеспечения, и в определенной степени исключить человеческие ошибки. Существующие системы мониторинга помогут в случае возникновения каких-либо нестыковок в работе.
В настоящее время существует большое количество систем контроля версий, и наиболее интересные и информативные варианты представлены в работе. Пока не существует идеальных систем, каждая из них обладает определенными недостатками, но одновременно с этим и рядом особенностей, которые выделяют ее.
На смену относительно старым системам (CVS) приходят улучшенные альтернативы. Другие системы более приятны и предоставляют лучший рабочий опыт. У потребителя, безусловно, есть много возможностей для выбора. Большинство производителей предлагают демонстрационные версии своих программных продуктов.
Системы контроля версий являются потрясающим решение проблем распространенных корпораций. Безусловно данная область будет развиваться и в дальнейшем возможно увеличение числа систем и существенная доработка существующих.
Список литературы
1. Википедия [Электронный ресурс] - Доступ к ст.: http://ru.wikipedia.org/wiki/
2. Новое поколение систем контроля версий [Электронный ресурс] - Доступ к ст.: http://www.techinfo.net.ru/docs/Version_Control_Systems.html
3. Available CVS Alternatives [Электронный ресурс] - Доступ к ст.: http://better-scm.berlios.de/aegis/
4. Википедия [Электронный ресурс] - Доступ к ст.: http://ru.wikipedia.org/wiki/CVS
5. Википедия [Электронный ресурс] - Доступ к ст.: http://ru.wikipedia.org/wiki/Subversion
6. OpenCM Overview [Электронный ресурс] - Доступ к ст.: http://www.opencm.org/
7. Aegis 4.24 [Электронный ресурс] - Доступ к ст.: http://aegis.sourceforge.net/
8. BitKeeper [Электронный ресурс] - Доступ к ст.: http://www.bitkeeper.com/Products.Advantages.html
9. Википедия [Электронный ресурс] - Доступ к ст.: http://ru.wikipedia.org/wiki/Perforce
10. Википедия [Электронный ресурс] - Доступ к ст.: http://wiki.darcs.net/DarcsWiki/ВведениеВDarcs
Приложение 1
Сравнение Subversion и CVS. [5]
|
Параметр |
Subversion |
CVS |
|
|
Возможности |
|||
|
Директории |
Отслеживает версии не только файлов, но и директорий. |
Версии директорий не отслеживаются, то есть структура директорий одна и та же (та, которая существует в хранилище на данный момент) для всех ревизий и всех веток. При извлечении старых состояний получаем правильные (старые) ревизии файлов, но в неправильной (существующей на момент извлечения) структуре директорий. |
|
|
Транзакции |
Атомарность многофайловых публикаций. |
Атомарность только на уровне однофайловых публикаций. Фактически публикация изменений в нескольких файлах разбивается на последовательность публикаций изменений отдельных файлов. Если такая публикация прервана, то часть файлов остается опубликованной, часть - не опубликованной. |
|
|
Наборы изменений |
Наборы изменений поддерживаются. |
Наборы изменений не поддерживаются. |
|
|
Модификации имён файлов |
Поддерживает копирование, перемещение и переименование файлов и директорий с сохранением истории изменений. |
При копировании, перемещении и переименовании файлов файл с новым именем не имеет никакой истории, то есть связь со старым именем и его историей версий полностью теряется. То же самое для файлов внутри директории при модификации её имени. |
|
|
Свойства (properties) |
С каждым файлом и директорией может быть связан произвольный набор свойств, состоящих из названия и значения. Свойства тоже находятся под управлением версиями. |
Свойства не поддерживаются |
|
|
Блокировки |
Поддерживается необязательная блокировка файлов (начиная с версии 1.2). |
Блокировки не поддерживаются, но есть похожий механизм, называемый слежение |
|
|
Ветви |
Ветви реализованы в пространстве путей. Это значит, что для создания ветви производится копирование директории (копия и будет ветвью). Создание таких копий -- быстрая и не ресурсоёмкая операция, потому что данные не дублируются, вместо этого публикуется новая версия, отличающаяся от предыдущей лишь расположением файлов. |
Ветви реализованы в «третьем измерении». Это значит, что файл на ветви адресуется тремя параметрами: путём в файловой системе, ревизией (или другим способом указания ревизии, например, временем), именем ветви. |
|
|
Метки |
Нет меток, как таковых. Вместо них используется иерархия директорий -- для метки создаётся отдельная директория (как и для ветви). Метка -- это ветвь, в которой по договоренности больше не делают изменений. Метка является копией помеченного состояния файлов и директорий. |
Метки поддерживаются. Метка адресует помеченное состояние файлов. |
|
|
Эффективность |
|||
|
Клиент-серверный обмен |
При любых обновлениях версий между клиентом и сервером передаются только различия между файлами, что может существенно уменьшить сетевой трафик. |
С сервера к клиенту передаются различия, с клиента на сервер объект передаётся полностью |
|
|
Двоичные файлы |
Одинаково эффективно работает как с текстовыми, так и с двоичными файлами. |
Работа с двоичными файлами менее эффективна: каждая новая версия сохраняется в хранилище полностью. |
|
|
Создание ветвей и меток |
Требуется небольшое фиксированное количество времени и дискового пространства |
Затраты времени велики (зависят от количества задействованных файлов). Имена ветвей и меток хранятся избыточно (во всех задействованных файлах). |
|
|
Накладные расходы в рабочей копии |
В служебных директориях рабочей копии хранится чистая копия. Поэтому операции просмотра и отката локальных изменений выполняются быстро (без обращения к хранилищу), однако размер рабочей копии на диске примерно в два раза больше, чем размер самих данных. |
Чистая копия не хранится, размер рабочей копии примерно равен размеру данных. Вследствие этого операции просмотра и отката локальных изменений требуют доступа к хранилищу и выполняются медленно. |
|
|
Расход памяти на стороне сервера |
Меньше |
Больше. |
Приложение 2
Сравнительная таблица систем контроля версий.
|
CVS |
Subversion |
Arch |
Monotone |
OpenCM |
Aegls |
Darcs |
Perforce |
||
|
Коммиты |
Не атомарные |
Атомарные |
Атомарные |
Атомарные |
Атомарные |
Атомарные |
атомарные |
Атомарные |
|
|
Перемещение и переименование файлов и директорий |
Нет |
Да |
Да |
Да |
Да |
Да |
Да |
? |
|
|
Копирование файлов и директорий |
Нет |
Да |
Нет |
Да |
Нет |
Нет |
Нет |
? |
|
|
Репликация, создание удаленной копии репозитория |
Нет |
да, с версии 1.4.0 (svnsync) |
Да |
Да |
Нет |
Да |
Да |
? |
|
|
Прием изменений из удаленного репозитория |
Нет |
через внешние скрипты (SVN::Mirror, svn-push) |
Да |
Да |
Нет |
Да |
Да |
Да |
|
|
Разграничение доступа к различным частям репозитория |
ограниченно, через "pre-commit hook scripts" |
да, через средства WebDAV, с версии 1.3.0 - встроен |
Да |
Да |
права доступа привязаны к branch |
Да |
Нет |
Да |
|
|
Changesets - объединение группы связанных изменений в разных файлах в один логический блок |
Нет |
частично реализовано |
Да |
Да |
Да |
Да |
Да |
||
|
Подробная история построчных изменений |
Да |
Да |
только в ViewARCH |
Да |
? |
Да |
Да |
Да |
|
|
Возможность получения отдельной директории из репозитория |
Да |
да |
только репозиторий целиком |
нет |
нет |
да |
нет |
да |
|
|
Контроль изменений в рабочей копии, до commit'а в репозиторий |
да, cvs diff |
Да |
Да |
Да |
да |
Нет |
Да |
Да |
|
|
Задание отдельного текста комментария для отдельного файла при commit'е |
нет, только на блок изменений |
Нет |
Нет |
Да |
? |
да |
Нет |
нет |
|
|
Качество и объем документации |
отлично |
отлично |
удовлетворитольное |
Хорошо |
Нормально |
среднее |
Хорошо |
объём большой, качество среднее |
|
|
Простота установки, зависимость от стороннего ПО |
хорошо, cvs есть в пакетах к системе, ничего доустанавливать не нужно |
При выборе Apache как сервера тянет Apache 2 и WebDAV. Часто есть в пакетах |
отлично |
Отлично |
хорошо |
работает под root, файлы SUID-root |
для сборки нужен Glasgow Haskell Compiler |
?; пакет полностью самодостаточен и не зависит от стороннего ПО |
|
|
Совместимость команд с CVS |
Да |
да |
частично |
частично |
Да |
Нет |
нет |
нет? |
|
|
Сервер для доступа по сети |
Да |
WebDAV+DeltaV или собственный протокол |
отлично (FTP, SFTP, WebDAV,SMB) |
хорошо (netsync) |
есть клиент/сервер |
слабо развит |
через HTTP, SSH или email |
p4d, p2p |
|
|
Web интерфейсы пользователя |
множество (WebCVS, ViewCVS, Chora, wwCVS) |
множество (ViewCVS, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac, SVN::RaWeb::Light, SVN Browser, Insurrection) |
ViewARCH, ArchZoom |
нет |
Нет |
да |
darcs.cgi |
p4web |
|
|
GUI интерфейсы пользователя |
множество (WinCVS, Cervisia (KDE)), встроенная поддержка во многих IDE |
множество (TortoiseSVN, RapidSVN, Jsvn) |
tlator, Octopy, ArchWay |
нет |
нет |
tkaegis |
нет |
p4v, p4win |
|
|
Лицензия |
GPL |
Apache/BSD-style |
GNU GPL |
GNU GPL |
GNU GPL, возможно поменяется на BSD или CPL |
GNU GPL |
GNU GPL |
все компоненты пакета распространяются бесплатно в бинарном виде и являются полностью функциональными; исключение составляет сервер p2d, который без приобретения лицензии предоставляет возможность иметь 2-х пользователей и 5 рабочих пространств; для Open Source проектов лицензия предоставляется бесплатно |
Размещено на Allbest.ru
...Подобные документы
Возможности системы контроля версий - программы, предназначенной для работы с изменяющимися документами. Ее свойства и практики использования. Внутреннее устройство хранилища. Рабочая копия версионируемых документов. Централизованные и распределённые СКВ.
презентация [381,7 K], добавлен 05.01.2014Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.
курсовая работа [8,7 M], добавлен 14.05.2014Назначение и устройство микропроцессорной системы контроля. Описание функциональной схемы микропроцессорной системы контроля. Расчет статической характеристики канала измерения. Разработка алгоритма функционирования микропроцессорной системы контроля.
курсовая работа [42,0 K], добавлен 30.08.2010Особенности решения задачи контроля и управления посещением охраняемого объекта. Создание системы как совокупности программных и технических средств. Классификация систем контроля и управления доступом. Основные устройства системы и их характеристика.
презентация [677,7 K], добавлен 03.12.2014Пакет средств разработки DirectX под Microsoft Windows, характеристика наборов COM-совместимых объектов в его составе. Ключевые особенности версий, шейдерные языки. Описание основных используемых функций. Исходный код программы, примеры ее работы.
курсовая работа [422,2 K], добавлен 16.02.2015Понятие, сущность, структура и виды операционных систем. Характеристика операционной системы Windows XP, требования к ее установке, сравнительный анализ версий, особенности настройки, обновления версии, установки драйверов устройств и добавление новых.
реферат [558,8 K], добавлен 20.10.2009Анализ существующих систем контроля и управления доступом различных фирм-производителей. Анализ технических и эксплуатационных характеристик различных систем, разработка системы контроля и управления доступом. Предложение плана реализации системы.
дипломная работа [2,7 M], добавлен 07.06.2011Понятие, назначение, задачи и классификация системы контроля и управления доступом, ее основные компоненты. Сравнительный анализ деятельности производителей данных систем: Legos, Parsec, PERCo. Выбор архитектуры системы, оборудование и его размещение.
дипломная работа [7,7 M], добавлен 07.06.2014Общие сведения о предприятии "Гранит-ВТ". Основной вид деятельности - производство вычислительных модулей общего назначения. Разработка программы, предназначеной для автоматизированной проверки версий всех компонентов изделия. Алгоритм работы программы.
отчет по практике [33,8 K], добавлен 23.12.2009Система контроля и управления доступом как базовый компонент интегрированных систем. Структура и основные элементы систем видеонаблюдения. Области применения и обзор программного обеспечения систем видеонаблюдения. Интегрированные системы безопасности.
дипломная работа [1,8 M], добавлен 25.07.2015Использование операционных систем Microsoft Windows. Разработка операционной системы Windows 1.0. Возможности и характеристика последующих версий. Выпуск пользовательских операционных систем компании, доработки и нововведения, версии Windows XP и Vista.
реферат [23,3 K], добавлен 10.01.2012Характеристики биометрических систем контроля доступа (БСКД) и обобщенная схема их функционирования. Статические и динамические методы аутентификации. Интеграция БСКД с системами видеонаблюдения. Применение БСКД для защиты систем передачи данных.
курсовая работа [58,4 K], добавлен 05.06.2014Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.
реферат [38,9 K], добавлен 25.10.2010Принципы работы систем контроля и управления доступом, принцип их работы и оценка возможностей. Сравнительное описание методов идентификации. Разработка информационно-компьютерной системы контроля и управления доступом. Создание аппаратной подсистемы.
дипломная работа [1,7 M], добавлен 26.07.2013Анализ архитектуры ОС Windows 8. Сравнение с предыдущими версиями (интерфейс Modern UI, работа с учетными записями, модель безопасности, диспетчер задач, история файлов, восстановление системы, Storage Spaces). Особенности различных версий Windows 8.
курсовая работа [289,1 K], добавлен 25.01.2016Особенности разработки системы автоматизированного контроля знаний специалистов по дефектоскопии. Обзор автоматизированных систем обучения и контроля знаний. Психологические механизмы усвоения знаний. Принципы создания эффективной тестирующей программы.
дипломная работа [1,8 M], добавлен 30.08.2010Понятие и структура дистрибутивов операционной системы Linux, история их возникновения и основные разработчики. Классификация дистрибутивов по характеру сборки и установки, доработка их готовых версий. Описание способов создания собственного дистрибутива.
курсовая работа [551,0 K], добавлен 02.04.2014Система контроля пропашных культур, увеличение эффективности использования пропашных сеялок за счет анализа качества посева. Выбор основных узлов монитора, интерфейса USB, узла звуковой сигнализации. Программное обеспечение системы контроля "Мрия-3.2".
курсовая работа [4,8 M], добавлен 15.05.2014Системы контроля и управления доступом: контроллерные и программные. Технические тенденции их развития. Структура и элементы систем видеонаблюдения, области их применения и программное обеспечение. Интегрированные системы безопасности, уровни интеграции.
дипломная работа [1,7 M], добавлен 13.10.2015Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.
дипломная работа [2,5 M], добавлен 21.12.2012
