Как установить mercurial на windows

Обновлено: 07.07.2024

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

Новичок - программист, который коснулся системы контроля версий, не очень хорошо ее понимая.

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

Объясните, как сделать что-то, а не как это реализовать.
Разберитесь с одним вопросом на ответ.
Ответьте четко и максимально кратко.
Изменить/расширить существующий ответ, а не создавать новый ответ на ту же тему.
Пожалуйста, предоставьте ссылку на Mercurial wiki или HG Book для людей, которые хотят узнать больше.

Установка/настройка

Работа с кодом

Пометка, ветвление, релизы, базовые показатели

Другой

Другие ссылки Mercurial

Как вы настраиваете его, чтобы игнорировать файлы?

Ignore настраивается в обычном текстовом файле с именем .hgignore в корне вашего хранилища. Добавьте его как обычный файл с:

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

Как вы видите, что не передано, или статус вашей текущей кодовой базы?

Чтобы увидеть список файлов, которые были изменены:

Это напечатает каждый файл, который был изменен вместе с его статусом, который может включать:

M - изменено. Файл был изменен, и изменения не были зафиксированы.
A - Добавлено. Файл не отслеживался ранее, но если вы совершите фиксацию, Mercurial начнет отслеживать его.
R - удалено. Файл отслеживался ранее, но если вы совершите коммит, Mercurial перестанет отслеживать его в этом и последующих коммитах.
? - Неизвестно. В настоящее время файл не отслеживается Mercurial. Фиксация не повлияет на него, если вы не используете hg add для его добавления.
! - отсутствует. Файл отслежен, но Mercurial не может найти его в рабочей копии.

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

Как вы создаете новый проект/репозиторий?

Как вы сравниваете две ревизии файла или ваш текущий файл и предыдущую ревизию?

Оба используют hg diff . Когда используется hg diff , все изменения в рабочей копии и подсказка (последний коммит) отображаются.

Для "Как вы сравниваете две ревизии файла?"

Приведенная выше команда будет отличаться между rev1 и rev2 файла "file.code".

Для "Как вы сравниваете ваш текущий файл и предыдущую версию?"

Приведенная выше команда будет отличаться между текущей версией "file.code" и последней версией (последней принятой).

Как мне взаимодействовать с Subversion?

Есть три способа:

преобразовать расширение клонирует существующий репозиторий Subversion в Mercurial. Это идет с Mercurial. Это работает примерно так:

Например, это захватит ствол хранилища memcached SixApart.

Расширение может постепенно вносить новые ревизии из хранилища Subversion в Mercurial (немного похоже на pull). Однако он не поддерживает получение версий Mercurial и отправку их обратно в Subversion (без Push). [XXX: исправьте это, если оно неверно] .

расширение hgsubversion . Во многих отношениях это наиболее сложное решение, поскольку для взаимодействия с хранилищем Subversion используется API Subversion. Он стремится стать мостом hg-svn. Он допускает полное повторное отключение ревизий (полное клонирование, извлечение и push), однако на момент написания этой статьи [XXX: исправьте это, если/когда оно станет неправильным] он все еще находится в разработке, и пока нет официальных релизов. Как следствие, он работает только с самой современной версией Mercurial (1.3 на момент написания статьи).

Он отображает теги и ветви (все теги предшествуют tags/ , чтобы отличать их от ветвей с одинаковыми именами).
Он поддерживает специальную ветку closed-branches для закрытия веток, которые удалены в Subversion.
Это требует , чтобы хранилище Subversion было размещено в соответствии с соглашением о стволе/ветвях/тегах.
Набор команд обычно hg svn <subcommand> , хотя он нацелен на интеграцию до такой степени, что вам не нужна часть 'svn' (т. Е. Он хочет обрабатывать клон Subversion настолько, насколько это возможно, как любой другой репозиторий Mercurial) .;

Это работает так:

ИЛИ (только для svn:// URL)

Проверка всего хранилища:

Утилита hgsvn ( дерево битовых массивов ). До недавнего времени это позволяло вам только клонировать и извлекать хранилище Subversion, но с hgsvn 0.1.7 он поддерживает Push. [Я не знаю, как хорошо это делает Push. Любой с большим опытом должен обновить это.] У этого есть следующие известные особенности:

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

Сегодня мы с вами установим Mercurial и изучим основы работы с ним.
Я буду работать на базе windows, но если вы используете macOS или linux, то ничего страшного - Mercurial работает со всеми системами. Хотя у Mercurial и есть удобный графический интерфейс в windows, я всё равно буду показывать работу именно в консоли, т.к. такого графического интерфейса нет под linux и mac. Под mac и linux существуют графические решения, но они отличаются от решения на windows, а команды в консоли везде будут одинаковые, за редкими мелкими исключениями. Кроме того, когда Вы набьёте руку - окажется, что работать с консолью удобнее.

Установка Mercurial HG

Важный момент при установке, чтобы все галочки были поставлены как на скриншоте ниже, чтобы всё у вас корректно работало.

Первичная настройка

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

Создаём в домашнем каталоге файл mercurial.ini со следующим содержимым:

У Вас, соответственно, будут свои имя и e-mail.

Начало работы с Mercurial, первые шаги.

Если вы уже знакомы с системами контроля версий то вероятно, вам не нужно объяснять, что такое инициализация проекта. Но если нет, то:

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

Для начала создадим проект с некоторым набором файлов.

Как видите, в моём случае проект называется project, и хранит в себе файлы index.php, а также файл functions.php, который расположен по адресу /inc/functions.php относительно корня проекта.

При этом, мы с вами держим в голове, что в каталоге learn находится сам проект, который (в моём случае) представляет собой директорию project.

Теперь инициализируем проект в нашей директории - для этого введем команду $ hg init project

Открываем каталог project, и видим, что там создалась директория .hg.

Собственно, это и говорит о том, что проект был инициализирован меркуриалом.

Директорию .hg менять настоятельно не рекомендуется! Это может привести к некорректно работе СКВ, или к поломке проекта с точки зрения СКВ - вы можете просто потерять все данные, которые прошли commit.

Теперь мы должны добавить файлы к проекту (для mercurial) и "закоммитить" их.

Commit (коммит, коммиты, закоммитить) - понятие во всех системах контроля версий, и подразумевает фиксацию состояния проекта в том виде, в каком нам нужно его сохранить. Теоретически, мы могли-бы просто скопировать каталог и вставить его, например, в каталог Projects backups, а саму сохраненную копию назвать как-то вроде "Project_30.04.2018". А чтобы было понятно, что это за резервная копия - добавить в корень резервной копии файл readme.txt, с подробным описанием. Но это долго и не так удобно по сравнению с коммитом, который делает это быстрее и удобнее.

Добавим файлы командой $ hg add.

Если посмотреть на скриншот выше, то можно увидеть, что при первой попытке добавить файлы в проект перед коммитом у меня не получилось. Так вышло, потому что я находился в директории learn, которая не была инициализирована как проект у Mercurial. Да и кроме того, работаем мы с проектом project, поэтому и зайти нужно сначала в него, а потом уже выполнять команду $ hd add - все это проделано на скриншоте выше.

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

А теперь закоммитим проект командой $ hg commit

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

Теперь давайте посмотрим состояние нашего проекта. Для этого пропишем команду $ hg status:

Как видим, Меркуриал нам ничего не показал. Но давайте для примера изменим какой-то файл. Я изменю файл index.php:

А теперь повторим команду $ hg status:

Как видим, меркуриал подсветил синим файл index.php и обозначил его индексом М.

А с помощью команды $ hg diff мы можем посмотреть изменения более подробно:

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

Добавим снова наш файл ($ hg add) и закоммитим его. Вот только на этот раз, мы не просто напишем команду $ hg commit - мы пропишем для нее ключ -m, чтобы прописать комментарий к коммиту прямо в командной строке. Получится такая команда:
$ hg commit -m "test commit width key m».

Ключ -m означает, что к коммиту мы собираемся добавить комментарий. Если мы попытаемся добавить комментарий без этого ключа - ничего не выйдет.

Видим, что бекап (коммит) создан, т.к. меркуриал после выполнения команды нам ничего не показал.

Команду $ hg status можно прописать аналогичной командой $ hg st - это будет тоже самое.

Логично, что резервные копии (коммиты) мы делаем для того, чтобы потом пользоваться ими. Значит, нам нужно научиться просматривать дерево коммитов (т.е. все коммиты, которые мы делали для данного проекта).

Чтобы посмотреть дерево (список) коммитов данного проекта, необходимо выполнить команду $ hg log:

И, как видим, мы посмотрели его содержимое.

Чтобы откатиться к какому-то коммиту, для начала давайте уйдём от текущего - т.е. от коммита 1. Для этого, необходимо создать новый коммит. А чтобы создать новый коммит - необходимо хоть что-то изменить хотя-бы в одном из файлов. Я внесу изменения в файл
index.php

Я сохраню его, выполню команды $ hg add и $ hg commit -m "new test commit" соответственно, и потом заново посмотрю дерево командой $ hg log:

А теперь сделаем откат к коммиту 1. Для этого выполним команду $ hg update -r 1.

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

Открываем файл index.php и видим, что мы действительно вернулись к его более ранней версии.

На этом всё, а в следующих статьях мы с вами будем более глубоко знакомиться с системой контроля версий Mercurial.

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

2018 © При копировании материалов сайта указание прямой ссылки на источник обязательно.

Недавно случайно узнал, что BitBucket, где лежат мои Mercurial-репозитории, прекращает поддержку Mercurial: новые репозитории создавать уже нельзя, а существующие будут удалелы с 1.06.2020. Возможные варианты действий: перейти на Git, выбрать один из других сервисов, или настроить хостинг Mercurial на своём сервере. Сервер у меня есть, отказываться от Mercurial и менять привычки как-то не хочется, альтернативы BitBucket мне тоже не приглянулись — поэтому выбрал последний вариант. Задача вроде несложная, вот только сервер у меня под Windows, и, кажется, в процессе настройки я умудрился наступить на максимум возможных граблей. Надеюсь, эта статья поможет кому-нибудь избежать этого и сэкономить время.

Различные варианты организации Mercurial-хостинга описаны в документации. Их можно разделить на 3 группы:

hg serve — т.е. сам Mercurial запускается в режиме сервера.
HgWeb.cgi — официальный скрипт, входящий в дистрибутив Mercurial.
Решения от внешних разработчиков — более функциональные, но со своими ограничениями и зачастую платные.

HG SERVE

Наиболее простым и логичным выглядит 1-й вариант. Как гласит документация, в Mercurial имеется встроенный веб-сервер, исполняющий HgWeb — именно он и работает, когда мы запускаем hg serve. Этот сервер не умеет делать аутентификацию, т.е. не умеет запрашивать логин/пароль пользователя, однако умеет делать авторизацию, т.е. давать/не давать тот или иной вид доспупа к репозиториям в соответствии с настройками доступа. Если нам нужны приватные репозитории, то для аутентификации можно использовать Nginx в качестве прокси-сервера, который будет запрашивать пароль. Настройка такой схемы описана здесь.

Для удобства hg serve запускается в виде сервиса с помощью winsw — утилиты, позволяющей запускать в виде сервиса любую команду (в данном случае это вообще bat-файл). Впрочем, для запуска можно обойтись и без сервиса, а, например, создать таск в Task Scheduler с триггером "At system startup" — такой таск будет запускаться при старте системы. Но это менее надёжный вариант: в случае сбоя таск не будет перезапущен, да и в логах информации об этом не будет.

Будьте внимательны с файлами конфигурации (hgweb.conf / hgrc):

Их содержимое чувствительно к регистру: если, например, написать [Web] вместо [web] — работать не будет.
Знак равенства обязательно должен быть окружен пробелами: если написать push_ssl=false — работать не будет, нужно писать push_ssl = false .

Ещё обратите внимание на то, что Mercurial делает push в репозиторий одним запросом, и если ваш проект не "Hello world", то этот запрос может быть объёмным и длительным. Пропишите в конфиге Nginx достаточно большие значения:

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

Проблема авторизации

В hgweb.conf задаётся общая для всех репозиториев конфигурация. Если нужны специфические настройки для каждого репозитория (а они нужны), то они указываются внутри репозитория: /.hg/hgrc Там можно, например, перечислить конкретных пользователей, имеющих доступ к данному репозиторию.

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

но у меня это не сработало :( Судя по коду HgWeb, имя пользователя берется из ENV('REMOTE_USER'), но вот как его туда поместить — загадка.

Если сложная авторизация не требуется, можно настроить её непосредственно в конфигурации Nginx либо создать 2 (или более) экземпляров hg serve, использующих различные файлы hgweb.conf . Недостаток в гибкости последнего метода в том, что настройки hgweb.conf глобальны и касаются всех (перечисленных в нем) репозиториев. Впрочем, комбинируя эти два метода можно добиться практически любых схем авторизации. В конце статьи я ещё коснусь этой темы.

HgWeb.cgi

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

Поскольку Nginx не умеет запускать CGI, а для WSGI нужен WSGI-сервер (поставить который на Windows отдельная проблема), я решил использовать FCGI — то есть FastCGI. Для его запуска нужен Python, причём документация гласит, что Python должен быть такой же версии, какая используется в бинарном дистрибутиве Mercurial — то есть 2.7. Окей, установил 2.7. Для запуска HgWeb в Python также необходимо установить библиотеку Flup, причём не просто установить, а определённой версии (ибо последняя не поддерживает Python 2.7). Вот так работает:

Теперь нужно отредактировать сам hgweb.fcgi — прописать путь к файлу конфигурации (что очевидно) а также указать параметры запуска, как минимум обязательный параметр используемого локального адреса (что совершенно неочевидно):

Осталось добавить конфигурацию Nginx:

Я специально не редактировал файл fastcgi.conf , а вынес все дополнительные настройки fastcgi в секцию location для наглядности. Обратите внимание на параметр PATH_INFO — он важен для работы скрипта. В моём случае имя скрипта в url вообще отсутствует, а весь оставшийся путь идёт в PATH_INFO.

Теперь запускаем сам скрипт:

Еще немножко настроек

Как и в случае с hg serve, разумно сделать запуск HgWeb в виде сервиса. Для этого использую всё тот же winsw. Он выполняет такой bat-файл:

Обратите внимание, что я скопировал python.exe в python-hg.exe чтобы taskkill легко нашел единственный нужный процесс для остановки.

Не стоит забывать и о безопасности: выполнять сервисы для публичного доступа под юзером "Local System" — плохая идея! Нужно создать отдельного юзера, дать ему доступ только к нужным папкам и запускать сервис под ним.

Публичный доступ к репозиториям

Чтобы организовать публичный беспарольный доступ к некоторым репозиториям, документация рекомендует запускать два экземпляра HgWeb (или hg serve) с разными конфигурациями. Но можно сделать проще: для каждого репозитория, к которому нужен публичный доступ, добавить в конфигурацию Nginx отдельную секцию location без защиты паролем. Примерно так:

Все — репозиторий Base доступен без пароля.

Надеюсь, эта статья поможет вам сэкономить время. Лично у меня на всё это ушло примерно полтора дня (с учётом того, что Python я увидел, можно сказать, впервые в жизни :-)

Различные варианты организации Mercurial-хостинга описаны в документации. Их можно разделить на 3 группы:

hg serve — т.е. сам Mercurial запускается в режиме сервера.
HgWeb.cgi — официальный скрипт, входящий в дистрибутив Mercurial.
Решения от внешних разработчиков — более функциональные, но со своими ограничениями и зачастую платные.

HG SERVE

Будьте внимательны с файлами конфигурации (hgweb.conf / hgrc):

Их содержимое чувствительно к регистру: если, например, написать [Web] вместо [web] — работать не будет.
Знак равенства обязательно должен быть окружен пробелами: если написать push_ssl=false — работать не будет, нужно писать push_ssl = false .

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

Проблема авторизации

HgWeb.cgi

Осталось добавить конфигурацию Nginx:

Теперь запускаем сам скрипт:

Еще немножко настроек

Публичный доступ к репозиториям

Все — репозиторий Base доступен без пароля.

На днях начал работать с Mercurial. На первый взгляд он охуенен. О чём здесь и поведаю.

Для тех, кто не в курсе, Mercurial, это система контроля версий. Типа SVN, но не SVN. Для тех, кто не в курсе что такое SVN, читать дальше бессмыссленно.

О меркуриале уже есть достаточно много информации, в том числе и на русском. Например:

Я попробую не расписывать подробно то, что уже неоднократно расписано, а описать свои впечатления. А так же показать, как человеку знакомому с Subversion, можно быстро пощупать Mercurial для, так сказать, первого ознакомления.

Так же просьба знающим людям тыкать меня носом в места, где я не прав.

Предыстория вкратце

Некоторые моменты я всё-таки повторю.

И вот появились децентрализованные системы, в которых всё на первый взгляд намного запутаннее (дополнительно всё запутывает моё монстрячество в паинте):

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

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

Децентрализованных систем контроля версий (DVCS) набралось уже достаточно: git, mercurial, bazaar, darcs. Самый офигенный из них git. Git настолько офигенен и настолько в нём всё легко и просто, что хрен разберёшься, как он вообще работает. Mercurial, хотя и не так офигенен, но несколько ближе к SVN и переходить с VCS на DVCS я решил с него.

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

Вот список преимуществ Mercurial перед SVN, которые я открыл уже с самого начала:

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

Недостатки

Из недостатков пока даже ничего крупного придумать не могу.

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

Ставим Mercurial на Windows

Так как я отмороженный виндузятник, описывать всё буду на примере винды.

Аналогично TortoiseSVN, для Mercurial есть TortoiseHg. Его можно для начала и поставить. Хотя настоящие поцаны вполне могут обойтись и без графических фишек.

Вау, Tortoise встроился в контекстное меню.

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

Читайте также: