Работа со слияниями Слияние — это основная часть работы с инструментами распределённого контроля версий. Вот несколько случаев, когда возникает необходимость объединить работу.
Поскольку слияние очень частая операция, Mercurial имеет простые средства её осуществления. Давайте рассмотрим процесс слияния. Начнем с еще одного клонирования репозитория (заметили насколько часто мы это делаем?) и внесения изменений в него.
$ cd ..
$ hg clone hello my-new-hello
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd my-new-hello
# Make some simple edits to hello.c.
$ my-text-editor hello.c
$ hg commit -m 'A new hello for a new day.'
Теперь у нас есть две копии hello.c c разным содержимым. История изменения этих двух репозиториев тоже различается, как показано на рисунке:
Рисунок 11 Развитие истории проекта
Каждый раз, когда мы делаем слияние, hg parents показывает двух родителей пока мы не закрепим результат командой hg commit.
$ hg commit -m 'Merged changes'
Теперь у нас есть новая главная ревизия. Заметим, что обе бывшие головы теперь родители. Это те же ревизии, что раньше отображались командой hg parents.
$ hg tip
changeset: 7:45b2a02b6844
tag: tip
parent: 5:2908f9fcaad4
parent: 6:c3e3be994861
user: Ilya Voronkov <iliaftk@outlook.com>
date: Thu Nov 22 14:10:24 2012 +0000
summary: Merged changes
Вы можете увидеть представление того, что происходит с рабочим каталогом при слиянии, и как это влияет на хранилище, когда происходит коммит. Во время слияния, рабочий каталог состоял из двух родительских ревизий, и они стали родителями новой ревизии.
Рисунок 12 Рабочий каталог до и вовремя слияния
Для использования разрешений конфликтующих изменений рекомендуется использования графических инструментов: пример- kdiff3, однако , на машину azure такой инструмент установить не удалось- поэтому я привожу пример графического из пособия:
Рисунок 13 kdiff3
Заключение
В данной работе были рассмотрены основные моменты использования системы контроля версий Mercurial. В тоже время основной упор в исследовании был сделан на установку системы для первого ознакомления. Автор работы плохо ознакомлен с системами Linux, и, входе работы приходилось использовать облачные системы для введение серверных решений для работы. Таким образом удалось доказать простоту внедрения системы контроля версий. В тоже время автору удалось в ходе работы ознакомиться с системами контроля и понять их важность использования в программных проектах. Особенно хочется отметить яркую направленность для пользователей Linux, так как установка на Windows требует хорошей подготовки в администрировании Windows Server 2008R2, знание структуру IIS. Приобретение подобных навыков позволит в будущем стать менеджером собственного проекта.
Стоит выделить возможность расширения функционала и хорошо организованную систему справок и консультаций. Минусом стоит признать отсутствие встроенного графического интерфейса, сложность интеграции с системами коммерческой направленности.