Основы VCS

Введение

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

О контроле версий

Что такое контроль версий, и зачем он вам нужен?

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

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

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

В простейшем случае вышеприведенную проблему можно решить хранением нескольких копий файлов, например, один для исправления ошибок в первой версии проекта и второй для новых изменений. Так как изменения обычно не очень большие по сравнению с размером файла, то можно хранить только измененные строки используя утилиту diff и позже объединять их с помощью утилиты patch. Но что если проект состоит из нескольких тысяч файлов и над ним работает сотня человек? Если в этом случае использовать метод с хранением отдельных копий файлов (или даже только изменений) то проект застопорится очень быстро. В последующих лекциях, для примеров я буду использовать исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.

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

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

Как уже говорилось ранее - один из примеров локальной СУВ предельно прост: многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы. Чтобы решить эту проблему, программисты уже давно разработали локальные СКВ с простой базой данных, в которой хранятся все изменения нужных файлов

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

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

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

Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.

Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный - централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё - всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.

CVS

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

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

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

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

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

Subversion

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

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

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

И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.

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

Зачем нужны распределенные системы?

Как следует из названия одна из основных идей распределенных систем - это отсутствие четко выделенного центрального хранилища версий - репозитория. В случае распределенных систем набор версий может быть полностью, или частично распределен между различными хранилищами, в том числе и удаленными. Такая модель отлично вписывается в работу распределенных команд, например, распределенной по всему миру команды разработчиков работающих над одним проектом с открытым исходным кодом. Разработчик такой команды может скачать себе всю информацию по версиям и после этого работать только на локальной машине. Как только будет достигнут результат одного из этапов работы, изменения могут быть залиты в один из центральных репозиториев или, опубликованы для просмотра на сайте разработчика, или в почтовой рассылке. Другие участники проекта, в свою очередь, смогут обновить свою копию хранилища версий новыми изменениями, или попробовать опубликованные изменения на отдельной, тестовой ветке разработки. К сожалению, без хорошей организации проекта отсутствие одного центрального хранилища может быть минусом распределенных систем. Если в случае централизованных систем всегда есть один общий репозиторий откуда можно получить последнюю версию проекта, то в случае распределенных систем нужно организационно решить какая из веток проекта будет основной. Почему распределенная система контроля версий может быть интересна кому-то, кто уже использует централизованную систему - такую как Subversion? Любая работа подразумевает принятие решений, и в большинстве случаев необходимо пробовать различные варианты: при работе с системами контроля версий для рассмотрения различных вариантов и работы над большими изменениями служат ветки разработки. И хотя это достаточно естественная концепция, пользоваться ей в Subversion достаточно не просто. Тем более, все усложняется в случае множественных последовательных объединений с одной ветки на другую - в этом случае нужно безошибочно указывать начальные и конечные версии каждого изменения, что бы избежать конфликтов и ошибок. Для распределенных систем контроля версий ветки разработки являются одной из основополагающих концепций - в большинстве случаев каждая копия хранилища версий является веткой разработки. Таким образом, механизм объединения изменений с одной ветки на другую в случае распределенных систем является одним из основных, что позволяет пользователям прикладывать меньше усилий при пользовании системой.

Краткое описание популярных распределенных СУВ

• Git - распределенная система контроля версий, разработанная Линусом Торвальдсом. Изначально Git предназначалась для использования в процессе разработки ядра Linux, но позже стала использоваться и во многих других проектах - таких, как, например, X.org и Ruby on Rails, Drupal. На данный момент Git является самой быстрой распределенной системой, использующей самое компактное хранилище ревизий. Но в тоже время для пользователей, переходящих, например, с Subversion интерфейс Git может показаться сложным;
• Mercurial - распределенная система, написанная на языке Python с несколькими расширениями на C. Из использующих Mercurial проектов можно назвать, такие, как, Mozilla и MoinMoin.
• Bazaar - система разработка которой поддерживается компанией Canonical - известной своими дистрибутивом Ubuntu и сайтом https://launchpad.net/ . Система в основном написана на языке Python и используется такими проектами, как, например, MySQL.
• Codeville - написанная на Python распределенная система использующая инновационный алгоритм объединения изменений (merge). Система используется, например, при разработке оригинального клиента BitTorrent.
• Darcs - распределенная система контроля версий написанная на Haskell используемая, например, проектом Buildbot.
• Monotone - система написанная на C++ и использующая SQLite как хранилище ревизий.

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

Система контроля версий (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» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии - это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.

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

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

Естественно, поиски были начаты с изучения Хабра - и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет:).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации . Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную , по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

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

Вступление

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

Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.

Используемые программы и сервисы

Для развертывания VCS (системы контроля версий) мы будем использовать следующие программы и сервисы:

• Mercurial - кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
• TortoiseHg - графический фронтенд для системы контроля версий Mercurial.
• Bitbucket - веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.

Развертывание система контроля версий – пошаговая инструкция

1. Скачиваем и устанавливаем к себе на компьютер TortoiseHg с официального сайта: http://tortoisehg.bitbucket.org/

Данный клиент необходимо будет устанавливать на всех компьютерах, с которых будет вестись совместная разработка проектов.

В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.

2. Регистрируемся в веб-сервисе Bitbucket: https://bitbucket.org/
Весь процесс регистрации сводится к заполнению контактных данных (Username, Email и т.д.) и подтверждения указанного при регистрации email-адреса нажатием на кнопку «Confirm this email address» в полученном после регистрации письме.

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

С полным списком тарифов вы можете ознакомиться, пройдя по ссылке: https://bitbucket.org/plans

3. Зайдя в ваш аккаунт в сервисе Bitbucket, вы можете сразу изменить язык интерфейса вашего аккаунта на русский.

Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса

4. Для создание репозитория для вашего проекта вам необходимо перейдите на главную страницу вашего аккаунта (https://bitbucket.org/dashboard/overview) и нажмите на кнопку «Создайте ваш первый репозиторий»

5. На странице создания нового репозитория укажите следующие настройки:

Имя – Укажите имя вашего нового репозитория. Данное имя используется для построения ссылки доступа к вашему репозиторию.
Важно! Лучше указывать имя латинскими буквами, иначе ссылка на репозитрий будет заканчиваться дефисами и иметь сложный к пониманию вид: httрs://вашлогин@bitbucket.org/вашлогин/--------

Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
- Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
- Создание форков – Поставьте «Разрешить только приватные форки»
- Тип репозитория – Выберите «Mercurial»
- Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
- Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.

По завершению указания всех настроек страница будет выгладить приблизительно так:

Еще раз проверьте введенные данные и если все введено корректно, жмем кнопку «Создать репозиторий».

6. После создания нового репозитория вы попадете на страницу «Начало работы»:

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

Важно! Папка должна быть пустой. Мне, например, для подключения папки с уже существующим проектом (кучей программного кода) пришлось временно перенести все файлы в другой каталог (сделать резервную копию - backup). Позже мы вернем все файлы на место, а пока нужно полностью очистить папку для подключения.

8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6

И нажать кнопку «Клонировать».

9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.

10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.

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

Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.

12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»

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

Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».

Система попросит подтвердить добавление, жмите «Добавить».

14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:

Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.

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

16. В открывшемся окне вы можете видеть всю историю сохраненных (зафиксированных) изменений в коде, можете откатить к нужной фиксации, а также отправить изменения в созданный вами ранее репозиторий.

Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».

После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.

Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.

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

Промежуточные итоги подключения системы контроля версий (VCS)

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

Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.

Подключение сотрудников к вашему репозиторию.

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

Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.

Подключение сотрудника к нашему репозиторию

18. Все сотрудники, которые будут иметь доступ к вашему репозиторию, должны быть зарегистрированы на сервисе Bitbucket. А также у них на компьютерах должен быть установлен TortoiseHg.

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

19. Зайдите в ваш аккаунт на сервисе Bitbucket:

Нажмите на кнопку «Отправить приглашение», расположенную в разделе «Пригласить участника на этот репозиторий».

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

После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».

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

Еще раз повторю, все участники вашего репозитория должны быть зарегистрированы в сервисе Bitbucket.

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

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

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

Данный подход мы применили для разработки проекта.

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

Версионирование

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

Source/ barbershop_index_final.psd

Всё хорошо, дизайнер закончил работу, но заказчик прислал в ответ правки. Чтобы была возможность вернуться к старой версии проекта, дизайнер создал новый файл barbershop_index_final_2.psd , внёс изменения и отправил заказчику:

Source/ barbershop_index_final.psd barbershop_index_final_2.psd

Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:

Source/ barbershop_index_final.psd barbershop_index_final_2.psd … barbershop_index_final_19.psd … barbershop_index_latest_final.psd barbershop_index_latest_final_Final.psd

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

Git

Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:

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

SomeGame/ | - saves | | - save001.sav | | - save002.sav | | … | | папка с сохранениями | | - game.exe | ...файлы игры

Файлы, необходимые для работы приложения, хранятся в рабочей области. В папке saves хранится история всех сохранений игры. Git сохраняет код вашего проекта по такому же принципу: сохранения попадают в специальную скрытую папку, а рабочей областью является содержимое корневой папки.

Основные понятия

GUI

Облегчить работу с Git и GitHub могут специальные программы . Такие программы в удобной форме показывают изменения в коде, список коммитов и обладают другими удобными возможностями. Обычно в подобных программах есть возможность выполнять стандартные Git команды: pull , push , commit прочие, — просто нажав на кнопку.

Вконтакте

Телеграм

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное

Учреждение высшего профессионального образования

«ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ» (ТУСУР)

Кафедра радиотехнических систем (РТС)

Курсовая работа

по курсу «Информационные технологии»

СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ

Студенты гр.121-3 Королев Д.О.,

Кулешов М.В., Садов Д.А., Таймасов С.С.

Руководитель Ноздреватых Б.Ф

Курсовая работа 46с., 31 рис., 2 табл., источников.

СИСТЕМА КОНТРОЛЯ ВЕРСИЙ, GIT, SVN, MERCURIAL.

В данной курсовой работе рассматриваются наиболее популярные системы контроля версий.

Цель работы - познакомится с системами контроля версий, разобраться в их работе, установке и настройке.

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

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

Курсовая работа выполнена в текстовом редакторе Microsoft Word 2010 и представлена в печатном и электронном виде.

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

Введение

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

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

3.3 Ветвления

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

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

3.6 Блокировки

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

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

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

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

5.1.2 Концепция

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

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

5.2.2 Установка

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

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

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

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

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

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

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

5.3.2 Концепция

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

Заключение

Приложение А

Приложение Б

Приложение В

Введение

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

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

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

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

В соответствии с поставленной целью необходимо решить следующие задачи:

Определить понятие системы контроля версий;

Понять, как работают такие системы;

Рассмотреть правила установки и запуска;

Проанализировать существующие системы контроля версий;

Рассмотреть основные виды данного рода систем.

Задачи работы предопределили ее структуру. Курсовая работа состоит из пяти глав, введения, заключения, списка литературы и приложения.

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

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

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

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

Использование СКВ, безусловно, обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков.

Системы контроля версий решают следующие проблемы:

Хранение версий файлов;

Возможность получить любые предыдущие версии хранимых файлов;

Просмотр изменений внесенных между заданными в запросе версиями;

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

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

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

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

По команде извлечения устанавливается соединение с сервером, и проект в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была сделана рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения СКВ.

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

При некоторых вариациях, определяемых особенностями системы и деталями принятого бизнес-процесса, обычный цикл работы разработчика в течение рабочего дня выглядит следующим образом:

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

2) Модификация проекта. Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием. Эта работа производится локально и не требует обращений к серверу СКВ.

3) Фиксация изменений. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер, либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания. СКВ может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в СКВ это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.

3.3 Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), создание версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в основную ветвь. Это может делаться командой слияния (merge), либо путём создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.

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

Три вида операций, выполняемых в системе управления версиями, могут приводить к необходимости объединения изменений:

Обновление рабочей копии;

Фиксация изменений;

Слияние ветвей.

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

Изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте;

Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически. Их объединение состоит в том, что изменения, сделанные в каждой версии проекта, копируются в объединяемую версию;

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

Конфликтующими обычно являются:

Удаление и изменение одного и того же файла или каталога;

Удаление и переименование одного и того же файла или каталога;

Создание в разных версиях файла с одним и тем же именем и разным содержимым;

Изменения в пределах одного текстового файла, сделанные в разных версиях, могут быть объединены, если они находятся в разных местах этого файла и не пересекаются. В этом случае в объединённую версию вносятся все сделанные изменения;

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

Во всех случаях базовой версией для слияния является версия, в которой было произведено разделение сливаемых версий. Если это операция фиксации изменений, то базовой версией будет версия последнего обновления перед фиксацией, если обновление -- то версия предыдущего обновления, если слияние ветвей -- то версия, в которой была создана соответствующая ветвь. Соответственно, сопоставляемыми наборами изменений будут наборы изменений, сделанных от базовой до текущей версии во всех объединяемых вариантах.

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

При определении допустимости слияния изменений в пределах одного и того же текстового файла работает типовой механизм построчного сравнения текстов (примером его реализации является системная утилита GNU diff), который сравнивает объединяемые версии с базовой и строит список изменений, то есть добавленных, удалённых и заменённых наборов строк. Найденные наборы изменённых строк, которые не пересекаются между собой, считаются совместимыми и их слияние делается автоматически. Если в сливаемых файлах находятся изменения, затрагивающие одну и ту же строку файла, это приводит к конфликту. Такие файлы могут быть объединены только вручную. Любые файлы, кроме текстовых, с точки зрения СКВ являются бинарными и не допускают автоматического слияния.

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

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

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

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

3.6 Блокировки

Механизм блокировки позволяет одному из разработчиков взять только в собственное использование файл или группу файлов для внесения в них изменений. На то время, пока файл заблокирован, он остаётся доступным всем остальным разработчикам только на чтение, и любая попытка внести в него изменения отвергается сервером. Технически блокировка может быть организована по-разному. Типичным для современных систем является следующий механизм:

Файлы, для работы с которыми требуется блокировка, помечаются специальным флагом «блокируемый»;

Если файл помечен как блокируемый, то при извлечении рабочей копии с сервера он получает в локальной файловой системе атрибут «только для чтения», что препятствует его случайному редактированию;

Разработчик, желающий изменить блокируемый файл, вызывает специальную команду блокировки (lock) с указанием имени этого файла. В результате работы этой команды происходит следующее:

1. сервер проверяет, не заблокирован ли уже файл другим разработчиком; если это так, то команда блокировки завершается с ошибкой.

2. файл на сервере помечается как «заблокированный», с сохранением идентификатора заблокировавшего его разработчика и времени блокировки;

3. если блокировка на сервере прошла удачно, на локальной файловой системе с файла рабочей копии снимается атрибут «только для чтения», что позволяет начать его редактировать.

Если в процессе работы выясняется, что файл изменять не нужно, он может вызвать команду снятия блокировки (unlock, release lock). Все изменения файла будут отменены, локальный файл вернётся в состояние «только для чтения», с файла на сервере будет снят атрибут «заблокирован» и другие разработчики получат возможность изменять этот файл;

По завершении работы с блокируемым файлом разработчик фиксирует изменения. Обычно блокировка при этом снимается автоматически.

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

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

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

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера. Номера версии отдельного файла здесь, фактически, не существует.

Однако оба варианта не слишком удобны. Для более удобной пометки версий проекта системы контроля версиями поддерживают понятие тегов.

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

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

Наиболее предпочтительной СКВ для слежения за домашними разработками будет локальный тип. Для решения этой задачи были разработаны специальные СКВ с простой базой данных, в которой хранятся все локальные файлы.

Рисунок 4.1 Схема локальной СКВ

Одной из наиболее популярных СКВ такого типа является RCS, которая до сих пор устанавливается на многие компьютеры.

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

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

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

Рисунок 4.2 Схема централизованного контроля версий

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

Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный -- централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё -- всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные СКВ подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.

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

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

Рисунок 4.3 Распределённая модель СКВ

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

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

С точки зрения пользователя распределённая система отличается необходимостью создавать локальный репозиторий и наличием в командном языке двух дополнительных команд: команды получения репозитория от удалённого компьютера и передачи своего репозитория на удалённый компьютер. Первая команда выполняет слияние изменений удалённого и локального репозиториев с помещением результата в локальный репозиторий; вторая -- наоборот, выполняет слияние изменений двух репозиториев с помещением результата в удалённый репозиторий. Как правило, команды слияния в распределённых системах позволяют выбрать, какие наборы изменений будут передаваться в другой репозиторий или извлекаться из него, исправлять конфликты слияния непосредственно в ходе операции или после её неудачного завершения, повторять или возобновлять неоконченное слияние. Обычно передача своих изменений в чужой репозиторий завершается удачно только при условии отсутствия конфликтов. Если конфликты возникают, пользователь должен сначала слить версии в своём репозитории, и лишь затем передавать их другим.

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

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

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

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

- Слежение за определённым файлом или группой файлов;

- Единая сквозная нумерация версий системы и/или файлов, в которой номер версии монотонно возрастает. В распределённых системах приходится обходиться локальными обозначениями версий и применять теги, назначение которых определяется соглашением между разработчиками или корпоративными стандартами фирмы;

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

Можно выделить следующие типичные ситуации, в которых использование распределённой системы даёт заметные преимущества:

- Периодическая синхронизация нескольких компьютеров под управлением одного разработчика. Использование распределённой системы избавляет от необходимости выделять один из компьютеров в качестве сервера;

- Совместная работа над проектом небольшой территориально распределённой группы разработчиков без выделения общих ресурсов. Как и в предыдущем случае, реализуется схема работы без главного сервера, а актуальность репозиториев поддерживается периодическими синхронизациями по схеме «каждый с каждым»;

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

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

5.1 GIT

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

Git работает под следующими операционными системами: Windows, Linux и Mac OS.

Для того, чтобы установить Git в Windows, требуется просто скачать exe-файл инсталлятора со страницы проекта на GitHub"е и запустите его. После установки у вас будет как консольная версия (включающая SSH-клиент), так и стандартная графическая.

5.1.2 Концепция

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

Таким образом, в проектах, использующих Git, есть три части: каталог Git"а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

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

Рабочий каталог -- это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git"а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов -- это обычный файл, обычно хранящийся в каталоге Git"а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git"а выглядит примерно так:

1. Вы вносите изменения в файлы в своём рабочем каталоге.

2.Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.

3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git"а на постоянное хранение.

Если рабочая версия файла совпадает с версией в каталоге Git"а, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым.

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

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

1. Через контекстное меню. Для этого нужно просто кликнуть правой кнопкой мыши в нужной директории и выбрать пункт Git Init Here.

Рисунок 5.1.1 Создание репозитория при помощи контекстного меню

2. С помощью командной строки. Для этого аналогично, в требуемой директории, в контекстном меню выбрать Git Bash. Откроется командная строка в которой создаем репозиторий при помощи команды Git Init.

Рисунок 5.1.2 Создание репозитория при помощи командной строки

Если вы никогда ранее не использовали git, для начала вам необходимо ввести имя и адрес электронной почти с помощью следующих команд, соответственно:

git config --global user.name "Your Name"

git config --global user.email [email protected]

Созданный репозиторий будет содержать директорию.git. Чтобы добавить файл в репозиторий требуется просто скопировать его в рабочую директорию. Добавим файл ex.txt в репозиторий. С помощью команды git status убедимся, что Git увидел файл.

Рисунок 5.1.3 Добавление и проверка файла в репозитории

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

Рисунок 5.1.4 Добавление файла под версионный контроль

Команда git status - основной инструмент, используемый для определения, какие файлы в каком состоянии находятся.

Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add «имя файла». Эта команда принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.

Git commit -m «комментарий» - команда для создания коммита, фиксирования изменения.

Через графический интерфейс Git Gui повторим предыдущую операцию. Для это в контекстном меню выберем пункт Git Gui.

Рисунок 5.1.5

В открывшемся окне выберем пункт «Создать новый репозиторий». Далее укажем каталог, в котором мы хотим разместить репозиторий.

Рисунок 5.1.6 Создание репозитория в Git Gui

Добавляем файл Ex.txt в каталог. Далее нажимаем кнопку «Перечитать». Для добавления файла в систему контроля версий требуется нажать кнопку «Подготовить все». Файл Ex.txt должен переместится из окна «изменено» в «Подготовлено». Для фиксирования изменения используется кнопка «Сохранить».

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

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

В этом разделе рассмотрим процесс создания учётной записи и нового проекта на GitHub"е. Это даст вам представление о вовлечённых в него вещах.

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

Первое, что нужно сделать, это настроить учётную запись и создать свой репозиторий на сайте http://github.com/plans.

Далее в командной строке Git вводим уже известные нам команды:

Git add ex.txt

Git commit -m "комментарий"

Git remote add origin https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Команда git remote add - добавление удалённых репозиториев, а команда git push - отправление локальных изменений на удаленный сервер.

Рисунок 5.1.7

Вводим логин и пароль указанные при регистрации:

Рисунок 5.1.8

Теперь наш проект размещён на GitHub"е, в репозитории - MyHomework с файлом Tusur.txt и мы можем дать ссылку на него любому, с кем захотим разделить проект.

Рисунок 5.1.9 Репозиторий на GitHub"е

5.2 TortoiseSVN

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

TortoiseSVN работает под операционной системой Windows XP (c Service Pack 3) или выше, и доступен как в 32-битной, так и в 64-битной версии. Установщик для 64-битной Windows также включает 32-битную часть.

5.2.2 Установка

TortoiseSVN поставляется в виде простого в использовании установочного файла.

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

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

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

TortoiseSVN - расширение проводника Windows, поэтому для начала нужно запустить проводник.

Рисунок 5.2.1 Вид в проводнике

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

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

Сначала создадим новую пустую директорию на ПК. Она может быть где угодно, но в этой работе мы собираемся назвать её s:\svn_repos. Теперь сделав правый клик на новой папке и в контекстном меню выберем TortoiseSVN > Создать здесь хранилище... Хранилище, созданное внутри папки, готово к использованию. Также мы создадим внутреннюю структуру папок, нажав кнопку «Создать структуру каталогов».

Рисунок 5.2.2 Создание репозитория

Рисунок 5.2.3 просмотр репозитория

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

Сейчас у нас есть хранилище, но оно совершенно пустое в данный момент. Давайте предположим, что у нас есть набор файлов в E:\ \TortoiseSVN, который мы хотели бы добавить. Перейдём к папке TortoiseSVN в Проводнике и сделаем правый клик на ней. Теперь выберем пункт TortoiseSVN > Импорт..., который вызовет диалоговое окно.

Рисунок 5.2.4 Окно импорта

К хранилищу Subversion обращаются по URL-адресу, который позволяет нам указать хранилище где угодно в Интернете. В данном случае нам нужно указать на наше локальное хранилище, которое имеет URL-адрес file:///s:/svn_repos, и к которому мы добавляем имя нашего проекта TortoiseSVN.

Другая важная функция данного диалога - это окно Сообщение импорта, в которое можно добавить сообщение о том, что мы делаем. Когда нам понадобится просмотреть историю проекта, эти сообщения будут ценным подспорьем для просмотра какие изменения и когда были сделаны.

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

Сейчас у нас есть проект в нашем хранилище, и нам надо создать рабочую копию для повседневной работы. Стоит отметить, что импортирование папки не превращает автоматически эту папку в рабочую копию. Для создания свежей рабочей копии в Subversion используется термин «Извлечь». Мы собираемся извлечь папку TortoiseSVN из нашего хранилища в папку для разработки называемую e:\ \TortoiseSVN\svn_repos. Создадим эту папку, затем сделаем правый клик на ней и выберите пункт TortoiseSVN > Извлечь... Введите URL-адрес для извлечения, в данном случае file:///s:/svn_repos/TortoiseSVN, и кликните на OK. Наша папка для разработки заполнится файлами из хранилища.

Внешний вид этой папки отличается от обычной папки. У каждого файла появился зелёный флажок в левом углу. Это значки статуса TortoiseSVN, которые присутствуют только в рабочей копии. Зелёный статус означает, что файл не отличается от версии файла, находящегося в хранилище.

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

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

Нажав правой кнопкой на одном из изменённых файлов, выберем команду TortoiseSVN > Различия. Запустится инструмент TortoiseSVN для сравнения файлов и покажет, какие точно строки в файлах были изменены.

Рисунок 5.2.5 Сравнение файлов

Теперь обновим хранилище. Это действие называется «Фиксировать изменения». Нажмём правой кнопкой на папке TortoiseSVN и выберем команду TortoiseSVN > Фиксировать. Появится диалог фиксации со списком изменённых файлов и напротив каждого будет галочка. Мы можем выбрать лишь несколько файлов из списка для фиксации.

Рисунок 5.2.6 Фиксация файлов

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

Во время работы над проектом, нам понадобится добавлять новые файлы, предположим мы добавили новые функции в файле и добавили справку в существующем файле. Нажмём правой кнопкой на папке и выберите команду TortoiseSVN > Добавить. Диалог добавления показывает все неверсированные файлы и мы можем выбрать те файлы, которые мы хотим добавить. Другой способ добавления файлов - это нажать правой кнопкой на самом файле и выбрать команду TortoiseSVN > Добавить.

Теперь, если мы откроем папку для фиксации, новый файл будет отображаться, как «Добавлен» и существующий файл как «Изменён».

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

Одной общей функцией всех систем управления ревизиями является функция, которая позволяет нам отменить изменения, которые мы внесли ранее.

Если мы хотим избавиться от изменений, которые мы еще не успели фиксировать и восстановить нужный файл в том виде, в котором он был перед началом изменений, то выберем команду TortoiseSVN > Убрать изменения. Это действие отменит наши изменения и вернет фиксированную версию файла, с которой мы начинали. Если же мы хотим убрать лишь некоторых изменения, то мы можете использовать инструмент TortoiseMerge для просмотра изменений и выборочного удаления измененных строк.

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

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

TortoiseSVN интегрируется непосредственно в оболочку Windows (т.е. в Проводник). Это значит, что вы можете работать с уже знакомыми инструментами, и вам не надо переключаться на другое приложение каждый раз, когда вам необходимы функции для управления версиями!

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

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

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

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

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

Все команды Subversion доступны из контекстного меню Проводника. TortoiseSVN добавляет туда собственное подменю.

5.3 Mercurial

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

П акеты Mercurial доступны для каждой популярной операционной системы: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Лучшей версией Mercurial для Windows является TortoiseHg, который можно найти на сайте http://tortoisehg.org. Этот пакет позволяет использовать командную строку и графический пользовательский интерфейс.

5.3.2 Концепция

Mercurial является распределенной (децентрализованной) системой контроля версий. Это означает, что рабочий процесс, как правило, выглядит следующим образом:

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

2. В рабочей директории данного репозитория изменяются/добавляются/удаляются файлы;

3. Выполняется фиксация (commit) изменений в данный репозиторий (то есть в локальный репозиторий на личном компьютере);

4. Шаги 2 и 3 повторяются столько раз, сколько необходимо;

5. При необходимости производится синхронизация изменений с другими репозиториями: забираются (pull) чужие наборы изменений и/или отдаются (push) собственные.

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

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

Работать в Mercurial можно через контекстное меню проводника, окно рабочей среды TortoiseHg Workbench (программа создает соответствующий ярлык при установке) или командную строку, используя команду hg.

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

В Mercurial все происходит внутри репозитория. Репозиторий проекта содержит все файлы, которые «относятся» к проекту, а также историю изменений этих файлов. Создать репозиторий можно тремя различными способами.

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

Рисунок 5.3.1 Создание репозитория

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

Рисунок 5.3.2 Расположение папки репозитория

Аналогично происходит создание репозитория непосредственно в окне TortoiseHg Workbench: последовательность Файл\Новое хранилище вызывает приведенное выше одноименное окно. В командной строке для создания репозитория в текущем каталоге используется команда hg init <имя хранилища>. Созданный репозиторий будет содержать каталог.hg.

Рисунок 5.3.3 Создание папки репозитория через командную строку

Если мы хотим добавить существующие файлы в репозиторий, мы копируем их внутрь рабочей директории, и с помощью команды hg add сообщаем Mercurial, что нужно начинать за ними следить. Добавим файл в репозиторий и создадим новую ревизию.

Рисунок 5.3.4 Добавление файла в репозиторий и создание новой ревизии

Убедимся, что Mercurial видит сохраненный файл. По команде status выводится состояние рабочей копии в сравнении с состоянием локального репозитория. Mercurial показывает, что видит файл example.txt, но этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). Для того, чтобы сказать Mercurial, что его необходимо версионировать, выполним hg add. Слева от имени файла появляется символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите (при создании новой ревизии), который выполняется командой hg commit.

В первый раз выполнение команды hg commit может пройти неудачно. Mercurial записывает ваше имя и адрес в каждую ревизию, чтобы вы или другие пользователи могли связаться с автором каждого изменения. Чтобы установить имя пользователя следует внести изменения в расположенный в каталоге.hg внутри рабочей директории файл hgrc. Первоначальное содержание этого файла должно выглядеть примерно так:

# This is a Mercurial configuration file.

username = Firstname Lastname [email protected]

Строка «» объявляет секцию конфигурационного файла. Вы можете прочитать «username =...» как «установить значение переменной username в секции ui». Секции продолжаются до начала новых секций. Пустые строки и строки, начинавшиеся с «#» игнорируются. Вы можете использовать любой текст в качестве значения username, так как эта информация предназначена для других людей, а не для интерпретации Mercurial"ом. В примере выше для этого использовалось распространенное соглашение: комбинация имени и адреса электронной почты.

Когда мы фиксируем изменения, Mercurial переводит нас в текстовый редактор, чтобы ввести комментарий, описывающий модификации, которые мы внесли в этом наборе изменений. Такое описание называется сообщением об изменениях (описанием изменений, описанием ревизии). Это будет записью для читателей о том, что мы сделали и почему, и будет выводиться при выполнении команды hg log после того, как мы закончим публикацию ревизии.

Редактор, который откроется при выполнении команды hg commit, будет содержать пустую строку и несколько строк, начинающихся с «HG:».

HG: Enter commit message. Lines beginning with "HG:" are removed.

HG: Leave message empty to abort commit.

HG: --

HG: user: user

HG: branch "default"

HG: changed example.txt

Mercurial игнорирует строки, начинающиеся с «HG:». Он использует их только для того, чтобы сообщить нам, изменения в каких файлах он запишет. Редактирование или удаление этих строк ни на что не повлияет. Если вы передумаете публиковать изменения во время редактирования комментария, просто выйдите из редактора без сохранения изменяемого файла. Это не вызовет изменений ни в репозитории, ни в рабочем каталоге.

Команда hg log по умолчанию выводит только первую строку описания изменений. Поэтому комментарий лучше написать так, чтобы первая строка была отделена. Для оставшейся части описания ревизии нет жестких правил. Сам Mercurial не обрабатывает и не заботится о содержимом сообщения об изменениях, хотя в вашем проекте могут быть правила, предписывающие определённое форматирование.

Повторим эти операции, используя графический интерфейс TortoiseHg Workbench. До добавления файла в рабочий каталог окно выглядит следующим образом.

Рисунок 5.3.5 Добавление файла в рабочий каталог

Перенесем файл в репозиторий и обновим окно, нажав на кнопку слева на панели инструментов. Добавим файл в систему контроля версий посредством соответствующей команды контекстного меню (аналог hg add).

Рисунок 5.3.6 Команда контекстного меню

Рисунок 5.3.7 Добавление файла

После того как файл добавлен, в правом верхнем окне записывается описание ревизии, а новая ревизия создается нажатием на кнопку «Фиксировать». В правом нижнем окне появляется запись о произведенных изменениях. Можно заметить, что изменения представляются в виде графов.

Рисунок 5.3.8 Графы изменений

Также фиксировать изменения можно командой Hg Commit в контекстном меню помещенного в репозиторий файла, не запуская Workbench.

Рисунок 5.3.9 Фиксация изменений

Команде hg log или hg diff здесь соответствует «Сравнить ревизии файла» (правый клик на имени файла).

Рисунок 5.3.10 Сравнение ревизий файла

В этом же окне можно вернуться к одной из предыдущих ревизий командой «Вернуться к ревизии…» или «Обратить изменения…» в основном окне. Продемонстрируем на примере, зафиксировав предварительно еще некоторые изменения файла example.txt. Выделенная красным строчка - обращенные изменения.

Рисунок 5.3.11 Отмена изменений

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

Хотя вы можете скопировать репозиторий как обычный каталог, лучше использовать встроенную команду Mercurial. Она называется hg clone, потому что создает идентичную копию существующего репозитория. Одно из преимуществ использования hg clone в том, что она позволяет клонировать репозитории по сети. Другим является то, что она запоминает, откуда мы его клонировали.

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

Создадим удаленную копию нашего хранилища (воспользуемся папкой Google Диск, которая сама по себе - облачный сервис), для чего выполним последовательность команд Файл\Клонировать хранилище в TortoiseHg Workbench. Результат представлен на следующем рисунке.

Рисунок 5.3.12 Создание удаленной копии хранилища

Mercurial позволяет передать изменения в другой репозиторий из репозитория, в котором мы в данный момент находимся. Добавим новую ревизию (под комментарием local change) в исходный репозиторий и выполним команду Хранилище\Синхронизация\Протолкнуть. Интерфейс рабочей среды позволяет выбрать только те ревизии, которые необходимо «протолкнуть». Обратим внимание, что в репозитории remote-vault была создана новая ветвь для полученной ревизии.

...

Подобные документы

Возможности системы контроля версий - программы, предназначенной для работы с изменяющимися документами. Ее свойства и практики использования. Внутреннее устройство хранилища. Рабочая копия версионируемых документов. Централизованные и распределённые СКВ.

презентация , добавлен 05.01.2014


Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.

дипломная работа , добавлен 21.12.2012


Анализ архитектуры ОС Windows 8. Сравнение с предыдущими версиями (интерфейс Modern UI, работа с учетными записями, модель безопасности, диспетчер задач, история файлов, восстановление системы, Storage Spaces). Особенности различных версий Windows 8.

курсовая работа , добавлен 25.01.2016


Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.

курсовая работа , добавлен 14.05.2014


Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.

реферат , добавлен 25.10.2010


Пакет средств разработки DirectX под Microsoft Windows, характеристика наборов COM-совместимых объектов в его составе. Ключевые особенности версий, шейдерные языки. Описание основных используемых функций. Исходный код программы, примеры ее работы.

курсовая работа , добавлен 16.02.2015


Windows как посредник пользователя и операционной системы, облегчая процесс общения между ними, история становления и развития ее первых версий. Функциональные особенности и отличия Windows 95/98/ME и Windows NT/2000/XP/Vista/7, их архитектурные решения.

презентация , добавлен 23.10.2013


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

дипломная работа , добавлен 19.01.2017


Понятие, сущность, структура и виды операционных систем. Характеристика операционной системы Windows XP, требования к ее установке, сравнительный анализ версий, особенности настройки, обновления версии, установки драйверов устройств и добавление новых.

реферат , добавлен 20.10.2009


Появление первых версий Windows, их графические интерфейсы и расширения для DOS. Семейства Windows 3.x и Windows 9.x, их особенности и основные функции. Эволюция технологии Plug and Play. Наиболее существенные улучшения в современных версиях Windows.