Для чего не должна применяться система управления версиями vcs

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

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

Ещё почитайте статью «Что такое API», я уверен она вам понравится.

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

Система контроля или управления версиями на английском будет Version Control System, сокращённо VCS, ещё иногда называют Revision Control System.

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

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

Типы контроля версий:

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

Централизованные VCS:

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

Централизованные системы:

Распределённые VCS:

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

Распределённые системы:

Возможности VCS:

Последние что стоит рассмотреть, это то какие возможности даёт контроль версий.

Вывод:

В этой статье вы прочитали что это такое система контроля версий, какие виды есть и возможности.

Источник

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

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

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

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

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

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

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

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

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

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

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

Источник

Как развернуть систему контроля версий (VCS) без командной строки

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

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

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

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

Вступление

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

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

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

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

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

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. После создания нового репозитория вы попадете на страницу «Начало работы»:

Где, нажав на ссылку «Я начинаю с полного нуля», сможете получить ссылку для подключения к вашему репозиторию с помощью TortoiseHg.

Ссылка будет иметь вид: httрs://вашлогин@bitbucket.org/вашлогин/имярепозитория

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

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

Далее нажимаем на пустой папке, предназначенной для хранения файлов проекта, подключенных к системе контроля версий Mercurial, правой кнопкой мыши и из выпадающего меню выбираем пункт «TortoiseHg->Clone…»

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Далее нажимаем правой кнопкой мыши на папке проекта и из выпадающего меню выбираем пункт «Hg Workbench…»

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.

23. Дальше вашему сотруднику необходимо выполнить 7 пункт данной инструкции для получения файлов проекта к себе на компьютер.

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

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

Данный подход мы применили для разработки проекта: АвтоОфис – платформа для интернет бизнеса

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

Источник

История систем управления версиями

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

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

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

Хронология выхода VCS

Для контекста, вот график c датами появления этих инструментов:

SCCS (Source Code Control System): первое поколение

SCCS считается одной из первых успешных систем управления версиями. Она была разработана в 1972 году Марком Рочкиндом из Bell Labs. Система написана на C и создана для отслеживания версий исходного файла. Кроме того, она значительно облегчила поиск источников ошибок в программе. Базовая архитектура и синтаксис SCCS позволяют понять корни современных инструментов VCS.

Архитектура

Как и большинство современных систем, в SCCS есть набор команд для работы с версиями файлов:

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

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

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

SCCS поддерживает ветви, которые хранят последовательности изменений в определённом файле. Можно произвести слияние ветви с исходной версией или с другой веткой.

Основные команды

Ниже приведён список наиболее распространенных команд SCCS.

Пример файла истории SCCS

RCS (Revision Control System): первое поколение

RCS написана в 1982 году Уолтером Тихи на языке С в качестве альтернативы системе SCCS, которая в то время не была опенсорсной.

Архитектура

У RCS много общего со своим предшественником, в том числе:

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

Основные команды

Ниже список наиболее распространённых команд RCS:

Пример файла истории RCS

CVS (Concurrent Versions System): второе поколение

CVS создана Диком Груном в 1986 году с целью добавить в систему управления версиями поддержку сети. Она также написана на C и знаменует собой рождение второго поколения инструментов VCS, благодаря которым географически рассредоточенные команды разработчиков получили возможность работать над проектами вместе.

Архитектура

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

Основные команды

Пример файла истории CVS

SVN (Subversion): второе поколение

Subversion создана в 2000 году компанией Collabnet Inc., а в настоящее время поддерживается Apache Software Foundation. Система написана на C и разработана как более надёжное централизованное решение, чем CVS.

Архитектура

Как и CVS, Subversion использует модель централизованного репозитория. Удалённым пользователям требуется сетевое подключение для коммитов в центральный репозиторий.

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

В настоящее время Subversion использует файловую систему FSFS (File System atop the File System). Здесь создаётся база данных со структурой файлов и каталогов, которые соответствуют файловой системе хоста. Уникальная особенность FSFS заключается в том, что она предназначена для отслеживания не только файлов и каталогов, но и их версий. Это файловая система с восприятием времени. Кроме того, директории являются полноценными объектами в Subversion. В систему можно коммитить пустые директории, тогда как остальные (даже Git) не замечают их.

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

SVN не использует обычную систему ветвления и тегов. Обычный шаблон репозитория Subversion содержит три папки в корне:

Основные команды

Пример файла истории SVN

Git: третье поколение

Систему Git разработал в 2005 году Линус Торвальдс (создатель Linux). Она написана в основном на C в сочетании с некоторыми сценариями командной строки. Отличается от VCS по функциям, гибкости и скорости. Торвальдс изначально написал систему для кодовой базы Linux, но со временем её сфера использования расширилась, и сегодня это самая популярная в мире система управлениями версиями.

Архитектура

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

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

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

Основные команды

Пример блоба, дерева и коммита Git

Блоб с хэшем 37d4e6c5c48ba0d245164c4e10d5f41140cab980 :

Объект дерева с хэшем b769f35b07fbe0076dcfc36fd80c121d747ccc04 :

Коммит с хэшем dc512627287a61f6111705151f4e53f204fbda9b :

Mercurial: третье поколение

Mercurial создан в 2005 году Мэттом Макколлом и написан на Python. Он тоже разработан для хостинга кодовой базы Linux, но для этой задачи в итоге выбрали Git. Это вторая по популярности система управления версиями, хотя она используется гораздо реже.

Архитектура

Mercurial — тоже распределённая система, которая позволяет любому числу разработчиков работать со своей копией проекта независимо от других. Mercurial использует многие из тех же технологий, что и Git, в том числе сжатие и хэширование SHA-1, но делает это иначе.

Наконец, Mercurial использует ещё один тип revlog, который называется changelog, то есть журнал изменений. Это список записей, которые связывают каждый коммит со следующей информацией:

Основные команды

Пример файлов Mercurial

Журнал изменений (changelog):

Дополнительная информация об устройстве Mercurial:

Источник