Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

Зачем это нужно

Сам я являюсь студентом технического ВУЗа и практически постоянно работаю с документами (текстами, рисунками, чертежами), изменяя их по три (десять, сто) раз на дню. Порой получается так, что правки, сделанные в течение последней недели, необходимо отменить и вернуться к документам в состоянии недельной давности. Хорошо, если правок было сделано немного, в этом случае могут помочь полсотни ударов по Ctrl+Z. Однако если в течение этой недели шла более-менее активная работа с документом, просто так восстановить статус «до важной правки, сделанной неделю назад» не получится. Для этого необходима копия документа на момент «до важной правки», а также еще десяток копий «до другой важной правки», «до сомнительной правки» и «до правки, которую, скорее всего, придется отменить». В принципе, такой подход возможен и практикуется многими. До недавнего времени я и сам держал важные версии файлов, сохраняя их с префиксами «дата_время», и, вроде бы, был доволен. Преимуществом этого метода является простота, недостатком – «разбухание» рабочих папок и неудобство использования. И, если с первым из них можно как-то бороться (большими жесткими дисками и 7zip’ом), то с неудобством что-то нужно было делать.

Что с этим можно сделать, или что такое СКВ

Вырываем абзац из Википедии: «Система управления версиями (от англ. Version Control System, VCS или Revision Control System) – программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое». Похоже на принцип работы самой Википедии – все версии статей со всеми правками доступны для изучения.
Таким образом, использование СКВ в ситуации, когда нужно хранить множество версий файлов – то, что надо. К преимуществам такого подхода относятся удобство использования и экономия свободного дискового пространства благодаря так называемому дельта-сжатию (когда сохраняются не сами файлы в различных версиях, а изменения от версии к версии, что уменьшает объем хранимых данных). Давайте попробуем.

Какие бывают СКВ

Та же Википедия подсказывает, что СКВ бывают централизованные и распределенные, большие и маленькие, с примочками и без. Нас это не особо интересует, так как мы будем пользоваться (по крайней мере, сначала) только частью функционала СКВ. Этот самый функционал и рассмотрим.
Практически все СКВ представляют собой некое хранилище, в котором хранятся все версии файлов, с которыми мы работаем. Здесь необходимо уточнить, что версии хранимых файлов чаще всего определяет пользователь. Внесли мы, допустим, с десяток мелких правок и решили, что пора бы сохранить результаты нашей деятельности в хранилище. В голову приходит аналогия с периодическим нажатием Ctrl+S, с тем лишь отличием, что к данной версии файла можно будет обращаться в будущем. Естественно, что «одним махом» таким образом можно занести в хранилище версии сколь угодно большого количества файлов. Называется это действие «commit», или «фиксация изменений» по-простому.
В любой момент в репозиторий (а именно так по-умному называется хранилище) можно добавить новый или удалить существующий файл, и СКВ будет «помнить» когда и что мы добавили/удалили. А благодаря комментариям при commit’ах можно еще и описать для чего собственно данный commit выполняется («добавили фенечку туда-то»/«удалили возможно нужный кусок оттуда-то»).
Когда же мы, наконец, понимаем, что пора бы нам вернуться к версии недельной давности, у нас имеется вся история изменений. И тут мы можем выбирать, как поступить. Если необходимо скопировать из старого файла нужный кусочек и вставить в текущую версию – просто извлекаем из хранилища старый файл и копируем из него необходимое. Если же необходимо полностью откатиться назад и продолжить работу со старой версией нам на помощь снова приходит СКВ – можно вернуться к ранней версии и создать так называемую новую ветку («branch»), сохранив при этом все, от чего мы «отказались», откатившись в версиях на неделю назад. Таким образом, историю версий проекта графически можно представить в виде дерева – от «корней» (начала проекта) до «ветвей» (удачных и неудачных правок). Кроме того, «ветку» можно создать и искусственно, к примеру, в том случае, когда из одних исходных файлов мы решим развить две различные версии – в первой работаем над одними фенечками, во второй – над другими. Более того, в случае, если рабочие файлы представляют собой текстовые документы (и в некоторых других), возможно объединение различных веток в одну – так называемое слияние («merge»). Теперь представим, что над проектом работают несколько человек, и каждый занимается своей такой «фенечкой». Наличие общего репозитория в этом случае сильно упрощает разработку.

От теории к практике, или начинаем использовать СКВ

Итак, надеюсь, я убедил вас в том, что использование СКВ – это хорошо. Осталось лишь научиться использовать СКВ. Этим и займемся.
Существуют различные системы контроля версий, отличающиеся друг от друга различными аспектами использования. Так как нас не интересуют (по крайней мере, сначала) тонкости работы различных систем, остановимся на самой простой и дружелюбной из них. По моему скромному мнению, такой системой, как ни странно, является Mercurial – «кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода» с графической оболочкой TortoiseHg. Работа с системой возможна под Windows, Linux и Mac OS X.
Сразу оговорюсь, что буду описывать работу с системой в Windows. Освоившим Linux не составит труда изучить все по аналогии.
Кроме того, параллельно обучимся работать с бесплатным хостингом Mercurial репозиториев – bitbucket.org, необходимым в случае, если вы работаете над проектом не одни или же, что очень удобно, хотите иметь доступ ко всем версиям проекта через интернет. По сути, это удобная замена Dropbox, если вы использовали его ранее.
Для начала устанавливаем Mercurial + TortoiseHg отсюда: tortoisehg.bitbucket.org.
Эта система работает в консоли, поэтому для удобства использования позже напишем несколько *.bat файлов для типичных операций.
Все операции производятся командой hg. Вызванная без параметров, она выводит список основных команд.
В качестве репозитория выступает любая выбранная нами директория (я буду использовать папку “C:\project\”), в которой и должны храниться все файлы нашего будущего проекта. Разумеется, никто не запрещает иметь несколько репозиториев на одном компьютере.
Чтобы система «поняла», что мы хотим создать репозиторий, выполняем команду:
hg init c:\project
после которой будет создана папка “c:\project\”, если она не была создана ранее и папка “c:\project\.hg\”, в которой Mercurial будет хранить всю служебную информацию.
Тут же вспоминаем, что хотим получить не только локальный репозиторий на своем компьютере, но и удаленный репозиторий, в который будем отправлять все наши изменения (или, как говорят умники, «пушить» изменения в удаленный репозиторий, от англ. «push»). Для этого идем на bitbucket.org, регистрируемся, и создаем свой первый репозиторий (Repositories - Create new repository). Даем репозиторию имя (я для определенности назову его remote_project) и жмем на Create repository.
Теперь у нас имеются два репозитория – локальный, находящийся в папке “c:\project\” и удаленный, расположенный по адресу “bitbucket.org/имя_вашей_учетки/remote_project/”, где имя_вашей_учетки – указанное при регистрации на bitbucket, remote_project – имя репозитория, выбранное при его создании.
Для того, чтобы продолжить изучение, нам необходимо поместить что-нибудь в наш локальный репозиторий. Просто создайте в нем (в моем случае – в папке “c:\project\”) любой файл вашего будущего проекта либо скопируйте туда ваш текущий проект.
Теперь, строго говоря, нам необходимо указать Mercurial: «мы добавили в папку проекта такой-то и такой-то файлы и пару новых папок», для этого предусмотрена команда “hg add”. Однако, более удобен другой подход – при очередном commit’е мы прикажем Mercurial подхватить все свежесозданные файлы из папки проекта и забыть про удаленные, это гораздо легче, чем каждый раз при создании нового документа выполнять “hg add c:\project\new_document.doc”.
Итак, приступаем к нашему первому commit’у. Выполняется он следующей командой:
hg commit –A –m “comment to commit”
Разберем все по порядку. Команда должна вводиться тогда, когда мы находимся в репозитории (то есть предварительно необходимо выполнить “cd c:\project”). Опция “-A” необходима для того, чтобы Mercurial «подхватил» свежесозданные файлы (см. выше), опция “-m” позволяет добавить к commit’у комментарий. Эти комментарии будут отображаться при просмотре версий (или changeset’ов – списков изменений) в TortoiseHg и на странице проекта в bitbucket.org. Очень важно давать осмысленные комментарии, чтобы потом не мучаться, вспоминая, когда же была сделана та или иная правка.
Теперь в нашем репозитории хранится начальная версия нашего проекта. Все дальнейшие commit’ы выполняются аналогично после того, как мы решим, что пора бы сохранить текущую версию.
Сделанный commit можно «втолкнуть» в удаленный репозиторий командой:
hg push https://bitbucket.org/имя_вашей_учетки/remote_project
При этом также необходимо находиться в папке, соответствующей репозиторию. После ввода команды будет запрошено имя и пароль нашей учетки на bitbucket.org, чтобы не вводить их при каждом push’е команду можно заменить на следующую:
hg push hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Так как все команды мы забьем в *.bat файл, в этом случае пароль будет храниться в открытом виде, что представляет собой некоторую угрозу безопасности, однако для меня это приемлемо.
Итак, для удобства создаем в зоне прямой досягаемости файлы commit.bat, push.bat и commit&push.bat со следующим содержанием:
[содержание файла commit.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
Этот файл, вызванный с аргументами, выполнит commit проекта с занесением аргументов в комментарии к commit’у. Пример: выполняем “commit.bat my first commit” и получаем commit с комментарием «my first commit». В FAR’е для этого удобно использовать сочетание Ctrl+Enter.
[содержание файла push.bat]
cd C:\project
hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Этот файл произведет push в удаленный репозиторий.
[содержание файла commit&push.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
call ./push.bat
Этот файл, вызванный с аргументами, выполнит последовательный commit и push проекта с занесением аргументов в комментарии к commit’у.
Кроме того, для мелких промежуточных commit’ов я рекомендую создать файл commit_date_time.bat:
[содержание файла commit_date_time.bat]
cd C:\project
hg commit -A -m "%DATE% %TIME%"
Этот файл произведет commit с указанием текущей даты и времени в качестве комментария, что часто бывает удобно.
Вопрос о частоте commit’ов и push’ей каждый решает в индивидуальном порядке в зависимости от интенсивности и сложности вносимых правок. Хотя и рекомендуется руководствоваться правилом «чаще – лучше».
Правым кликом на файле/папке репозитория можно запустить Repository Explorer (TortoiseHg - Repository Explorer), в котором представлены все наши commit’ы с комментариями к ним. В этом окне отображается древовидная структура нашего репозитория, отсюда же можно производить commit’ы, push’и, откаты к предыдущим версиям (backout’ы) и другие операции.
По адресу bitbucket.org/имя_вашей_учетки/remote_project находится аналогичный набор changeset’ов, при этом можно скачать любую версию проекта одним архивом, что иногда также очень удобно.
В общем, первоначальное знакомство с Mercurial на этом считаю оконченным. За более подробной информацией можно обратиться по адресу: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Для кого эта статья

Закончу, пожалуй, тем, с чего следовало бы начать – для кого эта статья? Ответ прост – для тех, кто хочет научиться использовать СКВ. Мне удалось «подсадить» на СКВ нескольких дизайнеров, инженеров и даже писателя. Попробуйте и вы – этим вы, возможно, сильно облегчите себе работу.

P. S. Перенес в блог «Системы управления версиями».

Теги: Добавить метки

Система контроля версий (Version Control System, VCS ) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS , принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

Наверное, всем знакома ситуация, когда при работе над проектом, возникает необходимость внести изменения, но при этом нужно сохранить работоспособный вариант, в таком случае, как правило, создается новая папка, название которой скорее всего будет “Новая папка” с дополнением в виде даты или небольшой пометки, в нее копируется рабочая версия проекта и уже с ним производится работа. Со временем количество таких папок может значительно возрасти, что создает трудности в вопросе отката на предыдущие версии, отслеживании изменений и т.п. Эта ситуация значительно ухудшается, когда над проектом работает несколько человек.

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository ) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy ) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit ) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update ).

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

Системы контроля версий можно разделить на две группы: распределенные и централизованные.

Централизованные системы контроля версий

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

CVS (Concurrent Versions System , Система одновременных версий) одна из первых систем получивших широкое распространение среди разработчиков, она возникла в конце 80-х годов прошлого века. В настоящее время этот продукт не развивается, это в первую очередь связано с рядом ключевых недостатков, таких как невозможность переименования файлов, неэффективное их хранение, практически полное отсутствие контроля целостности.

Subversion (SVN ) – система контроля версий, созданная на замену CVS . SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительном шагом вперед по сравнению с CVS.

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

Распределенные системы контроля версий (Distributed Version Control System, DVCS ) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

Большое преимущество такого подхода заключается в автономии разработчика при работе над проектом, гибкости общей системы и повышение надежности, благодаря тому, что каждый разработчик имеет локальную копию центрального репозитория. Две наиболее известные DVCS – это Git и Mercurial .

Начнем с Mercurial , эта система представляет собой свободную DVCS , которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg . Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla , OpenOffice , OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows , Mac OS , Linux ), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial . Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git , который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux . Среди крупных проектов, в рамках которых используется git , можно выделить ядро Linux , Qt , Android . Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial , доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS ), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS , удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git , крупные корпорации, подобные Google , используют свои VCS .

Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git .

Если вам больше нравится учиться по видео-лекциям , то рекомендуем классный курс по git от GeekBrains , перейдите по ссылке и найдите в разделе “Курсы” курс “Git . Быстрый старт” . Он бесплатный , нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!

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

Система контроля версий (cvs), 2017 — Сравниваем: Git, SVN, Mercurial

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

Если вы еще не знакомы с концепцией системы контроля версий , то вот все очень наглядно показано.

Или посмотрите видео от GitHub.

Итак, какая система контроля версий подойдет для вашего проекта?

Мы сравнили несколько популярных решений, чтобы вам было проще сделать выбор.

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

Системы контроля версий , в том числе широко известные SVN (Subversion) и Git, изначально создавались, чтобы команды разработчиков могли работать над совместными проектами, не создавая путаницы. В системе контроля не надо самостоятельно отслеживать ветви кода и изучать примечания к ним. Вместо этого используется центральный репозиторий, где всё упорядочено, структурировано. Здесь удобно обновлять файлы, добавлять комментарии и даже проводить слияние веток проекта.

Мнения в отношении того, какая система контроля версий самая лучшая, сильно разнятся, и это приводит к бурным спорам в среде программистов. Подбирая и изучая системы контроля версий для вашего проекта, не забывайте, что преимущества того или иного решения часто субъективны. Например, личные предпочтения программиста или, скажем, такие показатели как быстродействие, возможности плагинов IDE и т.д.

Главное отличие между системами контроля версий состоит в том, какие они: клиент-серверные или децентрализованные (p2p). Есть ли у них центральный репозиторий (сервер), откуда код берется и куда возвращается с внесенными изменениями. Или это копия в локальном хранилище, обновляемая посредством пиров: более децентрализованная сеть, используемая для синхронизации, обмена патчами (наборами изменений) и для поддержки текущего кода.

Стоит также учесть быстродействие, функциональность и порог вхождения/освоения конкретной системы контроля . Рассмотрим наиболее распространенные системы контроля версий и те причины, по которым программисты предпочитают те или иные решения.

Система одновременных версий (CVS )

CVS появилась в 1980-х и до сих пор популярна как у разработчиков коммерческих продуктов, так и у open-source разработчиков.

CVS распространяется на условиях Открытого лицензионного соглашения GNU и позволяет получать с сервера нужную версию проекта - « check-out» (извлечение) , а затем пересылать обратно на сервер, « check-in» (возврат), с внесенными изменениями.

Изначально CVS была создана, чтобы избежать конфликта версий. Всем участникам для работы предоставлялась только самая последняя версия кода. Это была первая система контроля версий. Пользователю нужно было быстро фиксировать изменения в репозитории, пока другие не опередили его.

Сейчас CVS имеет поддержку работы над проектами с ветками кода. Получается несколько вариантов продукта с разными характеристиками, которые можно будет объединить позднее.

Сервера CVS обычно работают под управлением Unix, но CVS -клиенты доступны и в других популярных операционных системах. CVS - «зрелая», проверенная временем система контроля версий . Это по-прежнему опенсорсная система, но на сегодняшний день новые функции добавляются довольно редко.

При этом CVSNT, - выделившаяся в отдельный проект версия CVS для серверов Windows, - сейчас достаточно активно расширяет функционал.

Преимущества:

• Испытанная временем технология, которая удерживается на рынке десятки лет.

Недостатки:

• Переименование или перемещение файлов не отражается в истории
• Риски безопасности, связанные с символическими ссылками на файлы
• Нет поддержки атомарных операций, что может привести к повреждению кода
• Операции с ветками программного кода дорогостоящие, так как эта система контроля не предназначена для долгосрочных проектов с ветками кода

Apache Subversion (SVN)

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

Как и CVS , SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.

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

Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.

В то время как в CVS операции с ветками кода дорогостоящие и не предусмотрены архитектурой системы, SVN создана как раз для этого. То есть, для более крупных проектов с ветвлением кода и многими направлениями разработки.

В качестве недостатков SVN упоминаются сравнительно низкая скорость и нехватка распределенного управления версиями. Распределенный контроль версий использует пиринговую модель, а не централизованный сервер для хранения обновлений программного кода. И хотя пиринговая модель работает лучше в open source проектах, она не идеальна в других случаях. Недостаток серверного подхода в том, что когда сервер падает, то у клиентов нет доступа к коду.

Преимущества:

• Система на основе CVS
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель

Недостатки:

• Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с репозиторием
• Сравнительно небольшая скорость

Git

Эта система была создана для управления разработкой ядра Linux и использует подход, который в корне отличается от CVS и SVN.

В основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий , в противовес правилам и решениям, использованным в CVS . Так как Git разрабатывалась главным образом под Linux, то именно в этой ОС она работает быстрее всего.

Git также работает на Unix-подобных системах (как MacOS), а для работы на платформе Windows используется пакет mSysGit.

Программный код может быть недоступен, когда используется компьютер без репозитория. Для решения этой проблемы есть обходные пути и некоторые разработчики полагают, что быстродействие Git является справедливой платой за неудобства.

Кроме того, в Git есть множество инструментов для навигации по истории изменений. Каждая рабочая копия исходного кода содержит всю историю разработки, что крайне полезно, когда программируешь без Интернет-соединения.

Преимущества:

• Прекрасно подходит для тех, кто ненавидит CVS /SVN
• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная оффлайн
• Распределенная, пиринговая модель

Недостатки:

• Высокий порог вхождения (обучения) для тех, кто ранее использовал SVN
• Ограниченная поддержка Windows (по сравнению с Linux)

Mercurial

Mercurial была выпущена одновременно с Git. Это также распределенная система контроля версий .

Mercurial создавалась в качестве альтернативы Git для разработки модулей ядра Linux. Но так как выбрали все-таки Git, то Mercurial используется меньше. Тем не менее, многие ведущие разработчики работают именно с этой системой, например OpenOffice.org .

Система контроля версий Mercurial отличается от других систем контроля версий тем, что главным образом она написана на Python (а не С). Однако, некоторые части выполнены в качестве модулей-расширений на C.

Поскольку система децентрализованная и написана на Python, многие Python-программисты склоняются к переходу на Mercurial.

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

Один из существенных недостатков Mercurial заключается в том, что в отличии от Git в ней нельзя объединить две родительские ветки, так как Mercurial использует систему плагинов, а не поддержку скриптов. Это отлично подходит для некоторых программистов, но многие не хотят отказываться от возможностей Git.

Преимущества:

• По сравнению с Git легче в освоении
• Подробная документация
• Распределенная модель системы контроля версий

Недостатки:

• Нет возможности слияния двух родительских веток
• Использование плагинов, а не скриптов
• Меньше возможностей для нестандартных решений

Какая система контроля версий мне подходит ?

В большинстве случаев разработчики используют CVS потому что это им привычнее. Если команда уже работает над проектом, то перспектива переноса всех наработок в другую систему контроля как-то не вдохновляет. Если бы им все-таки пришлось менять систему, то, скорее всего, они переключились бы на SVN.

CVS уже достигла статуса “зрелой технологии”, а это значит, что в ней уже не появится радикально новых функций и решений. Инерция привычки теряется, так как люди переходят на SVN. А значит CVS постепенно уходит в прошлое.

Сегодня SVN удерживает пальму первенства среди серверных систем контроля версий . Она включает в себя преимущества CVS и превосходит их. Если же говорить о распространенности, то вы, скорее всего, будете чаще сталкиваться с CVS или SVN, чем с Git или Mercurial. Таким образом, знание одной серверной технологии, хотя и не является необходимым, облегчит вам переход.

Благодаря широкому использованию и зрелости технологии, в SVN накоплена большая база знаний, что дает пользователям возможность легко получать помощь.

У Git явно выше быстродействие по сравнению с конкурентами. Для проектов, которые создаются под распределенные системы контроля версий , это очевидное улучшение.

Существенным недостатком Git является то, что порой трудно объяснить нюансы работы данной системы контроля , и это тормозит рабочий процесс, пока программисты привыкают к ней. Однако, как только «порог вхождения» преодолен, продуктивность возрастает и удобство управления ветками кода сполна окупит потраченное время.

Для тех, кто терпеть не может Git (а у этой системы есть свои противники в среде разработчиков), Mercurial - это компромисс между SVN и Git. Эта система используется во многих известных проектах, а также у нее хорошая документация.

Совместимая с Windows версия Git также прогрессирует, приближаясь по своему быстродействию к Linux-версии, так что эта система может быть для вас актуальна, даже если вы не ведете разработку в Linux.

Чтобы понять, какая же лучше для вас, учитывайте особенности проекта и вашей команды. Поговорите с разработчиками!

Если для проекта требуется единое дерево исходного кода, над которым будет работать небольшая группа программистов, то SVN – это ваш вариант. Она надежна и предназначена как раз для таких случаев.

Если же вы запускаете open-source проект, над которым в разное время будут трудиться несколько программистов или, если предполагается постоянное обновление кода, то выбирайте Git. Скорость и управление деревом исходного кода здесь намного лучше, чем в SVN.

Если вы на распутье или вам просто не нравится, как работают SVN или Git, тогда к вашим услугам Mercurial.

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

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

Приступая к работе с SVN

Если вы никогда не работали с SVN или Git, и понятия не имеете, как начать, то хостинговое решение в сочетании с графическим интерфейсом помогут вам быстро освоиться.

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

ПРИМЕЧАНИЕ: Есть множество хостинговых решений для системы контроля версий , в том числе с бесплатным пробным периодом. Вы можете создать на их базе свой первый репозиторий (место для совместной работы с файлами кода) совершенно бесплатно. Вот некоторые из этих сервисов:

Хостинг SVN & GIT

Создание первого репозитория

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

• Войдите в свой аккаунт, кликните по вашим проектам.
• Создание проекта:

• В строке «Create a New Project» введите имя вашего проекта
• Кликните по кнопке «Create Project»

• Подключение SVN:

• После создания проекта, выберите вкладку «Source Control» (версиями исходного кода)
• Кликните по ссылке «Enable Source Control»
• Присвойте репозиторию имя
• Нажмите «Save»

Графические клиенты SVN и GIT

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

— удобная программа для работы с системами контроля версий в Microsoft Windows и, возможно, лучший из представленных Apache Subversion клиент. TortoiseSVN реализован как расширение оболочки Windows, что позволяет легко интегрировать его в браузер. Кроме того, это программа с открытым исходным кодом, для которой доступны 34 языковых пакета

SmartGit

– графический клиент Git (Open Source распределенная система контроля версий ). Работает в Windows, Mac OS X и Linux. Стоимость лицензии - $39

«Извлечение» репозитория (“Checkout”)

Итак, клиент выбран. Теперь необходимо создать репозиторий для системы контроля. Нужно ввести URL-адрес вашего репозитория, имя пользователя и пароль.

URL-адрес обычно выглядит так: https://svn.hostname.com/svn/ > (вы можете использовать https:// (SSL), если у вас платный аккаунт)

1. Перейдите в корневую папку, нажмите кнопку «Check Out» («Извлечение») и создайте рабочую папку для клиента. Теперь вы можете добавлять в нее файлы.
2. После извлечения файлов проекта вы сможете редактировать их в локальной директории на вашем компьютере.

После внесения изменений в файлы для их сохранения нажмите кнопку «Check-in» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии - это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.

В вашем клиенте также должна быть предусмотрена возможность в любой момент начать работу с ревизиями, открыв журнал ревизий или историю изменений - тогда, если понадобится, вы сможете сделать «откат» к предыдущей версии для каждого файла в отдельности. Теперь, когда вы знакомы с базовыми концепциями, документация

RCS (Revision Control System, Система контроля ревизий) была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy). Система позволяет хранить версии только одного файла, таким образом управлять несколькими файлами приходится вручную. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ",v" . Например для файла file.txt версии будут храниться в файле file.txt,v . Для хранения версий система использует утилиту diff , то есть хранятся только изменения между версиями.

Рассмотрим пример сессии с RCS (знак $ здесь и далее обозначает приглашение операционной системы). Когда мы хотим положить файл под контроль RCS мы используем команду ci (от check-in, регистрировать):

$ ci file.txt

Данная команда создает файл file.txt,v и удаляет исходный файл file.txt (если не сказано этого не делать). Также эта команда запрашивает описание для всех хранимых версий. Так как исходный файл был удален системой мы должны запросить его обратно, что бы вносить изменения. Для этого мы используем команду co (от check-out, контролировать):

$ co file.txt

Эта команда вынимает последнюю версию нашего файла из file.txt,v . Теперь мы можем отредактировать файл file.txt и после того как закончим изменения опять выполнить команду ci для того что бы сохранить новую измененную версию файла:

$ ci file.txt

При выполнении этой команды система запросит у нас описание изменений и затем сохранит новую версию файла.

Хотя RCS соответствует минимальным требованиям к системе контроля версий она имеет следующие основные недостатки, которые также послужили стимулом для создания следующей рассматриваемой системы:

• Работа только с одним файлом, каждый файл должен контролироваться отдельно;
• Неудобный механизм одновременной работы нескольких пользователей с системой, хранилище просто блокируется пока заблокировавший его пользователь не разблокирует его;

CVS

CVS (Concurrent Versions System, Система совместных версий) пока остается самой широко используемой системой, но быстро теряет свою популярность из-за недостатков которые я рассмотрю ниже. Дик Грун (Dick Grune) разработал CVS в середине 1980-х. Для хранения индивидуальных файлов CVS (также как и RCS) использует файлы в RCS формате, но позволяет управлять группами файлов расположенных в директориях. Также CVS использует клиент-сервер архитектуру в которой вся информация о версиях хранится на сервере. Использование клиент-сервер архитектуры позволяет использовать CVS даже географически распределенным командами пользователей где каждый пользователь имеет свой рабочий директорий с копией проекта.

Как следует из названия пользователи могут использовать систему совместно. Возможные конфликты при изменении одного и того же файла разрешаются тем, что система позволяет вносить изменения только в самую последнюю версию файла. Таким образом всегда рекомендуется перед заливкой своих изменений обновлять свою рабочую копию файлов на случай возможных конфликтующих изменений. При обновлении система вносит изменения в рабочую копию автоматически и только в случае конфликтующих изменений в одном из мест файла требуется ручное исправление места конфликта.

CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.

Рассмотрим небольшой пример сессии с CVS. Прежде всего надо импортировать проект в CVS, это делается с помощью команды import (импортировать):

$ cd some-project $ cvs import -m "New project" path-in-repository none start

Здесь опция -m позволяет задать описание изменений прямо в командной строке и если ее опустить, то будет вызван текстовый редактор. Далее указывается путь по которому проект будет храниться в репозитории (path-in-repository в нашем случае) и после него две метки: метка разработчика (может пригодится в случае использования CVS для работы над проектами разработанными кем-то другим) и метка проекта.

После того как мы залили наш проект в репозиторий необходимо создать новый директорий в котором будет находится рабочая копия проекта под контролем CVS и загрузить проект с помощью команды checkout (контроль), или сокращенно co :

$ cd some-working-dir $ cvs checkout path-in-repository

Для команды checkout мы указываем путь к нашему проекту в репозитории который мы указывали выше в команде import .

Теперь мы можем внести в проект изменения и залить их в репозиторий с помощью команды commit (совершить изменения), или сокращенно ci :

$ cvs commit -m "Some changes"

Также как и для команды import мы указываем комментарий к нашим изменениям с помощью опции -m .

Если мы хотим обновить наш рабочий директорий новой версией проекта из репозитория мы используем команду update (обновить), или сокращенно up :

$ cvs update

CVS использовалась большим количеством проектов, но конечно не была лишена недостатков которые позднее привели к появлению следующей рассматриваемой системы. Рассмотрим основные недостатки:

• Так как версии хранятся в файлах RCS нет возможности сохранять версии директорий. Стандартный способ обойти это препятствие - это сохранить какой-либо файл (например, README.txt) в директории;
• Перемещение, или переименование файлов не подвержено контролю версий. Стандартный способ сделать это: сначала скопировать файл, удалить старый с помощью команды cvs remove и затем добавить с его новым именем с помощью команды cvs add ;

Subversion

Subversion (SVN) был разработан в 2000 году по инициативе фирмы CollabNet . SVN изначально разрабатывался как "лучший CVS" и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру. Из наиболее значительных изменений по сравнению с CVS можно отметить:

• Атомарное внесение изменений (commit). В случае если обработка коммита была прервана не будет внесено никаких изменений.
• Переименование, копирование и перемещение файлов сохраняет всю историю изменений.
• Директории, символические ссылки и мета-данные подвержены контролю версий.
• Эффективное хранение изменений для бинарных файлов.

Рассмотрим примеры команд, хотя надо заметить, что большинство из них практически повторяют команды CVS. Что бы использовать проект с SVN его надо сначала импортировать в репозиторий с помощью команды import (импортировать):

$ cd some-project $ svn import -m "New project" path-in-repository

В отличие от CVS не нужно указывать метки разработчика и проекта, которые не часто использовались на практике.

Теперь нам нужно создать рабочую копию проекта с помощью команды checkout (контроль), или co :

$ cd some-working-dir $ svn checkout path-in-repository

После внесения изменений мы используем команду commit (совершить изменения) , или ci для сохранения изменений в репозитории:

$ svn commit -m "Some changes"

И для обновления рабочей копии проекта используется команда update (обновить), или up .

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

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

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

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

Большинство систем управления версиями предоставляют следующие возможности:

• позволяют создавать разные варианты одного документа (ветки) с общей историей изменений до точки ветвления и с разными - после нее;
• дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле;
• ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии;
• контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.

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

Начало работы с системой. Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо с помощью специальной команды, фактически выполняющей то же самое действие. Разработчик задает версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.

Ежедневный цикл работы. Обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом:

• обновление рабочей копии : по мере внесения изменений в основную версию проекта рабочая копия на компьютере разработчика стареет и расхождение ее с основной версией проекта увеличивается, это повышает риск возникновения конфликтных изменений (см. ниже), и возникает необходимость поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, поэтому разработчик выполняет операцию обновления рабочей копии (update) насколько возможно часто, что определяется частотой внесения изменений, зависящей от активности разработки, числа разработчиков, а также от времени, затраченного на каждое обновление;
• модификация проекта : разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием, эта работа производится локально и не требует обращений к серверу VCS;
• фиксация изменений: завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер (либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания).