Давно еще перевел все проекты с svn на HG на сервис bitbucket. Очень доволен. Сама идеология mercurial очень доставляет.
Такое ощущение, что в этой части несколько развенчан миф об удобстве hg serve по сравнению с поднятием сервера для Git.
А вот отдельная команда hg outgoing Меркуриалу в плюс. Посмотрим, что будет дальше :-)
Каким же образом развенчан?
Тем, что на пальцах объёснить поднятие сервера с авторизацией не получилось :-) А для внутренней сети можно и общую папку на сервере сделать.
Рискну предположить, что искаробочный сервер для этого и не предназначен.
Если точнее, авторизацию ни одна из VCS (кроме грядущей veracity и вроде как fossil) не умеет. Следовательно, встроенная вебморда тоже не обязана авторизовывать юзеров.
классные статьи, Джоэль молодец, переводчик тоже
поставил ради интереса, довольно удобно
Хорошо что переводы так часто выходят. Главное — не бросайте на пол пути.
В планах примерно такой же темп. Осталось всего три части, опять же.
Спасибо.

Вопрос: hg serve достаточно надежён, чтобы жить в «диком интернете»? И как у него с потреблением ресурсов при достаточно долгой работе (месяцами, хотя и с небольшим числом push/poll — 2-3 раза в день) без перезапусков?
У него нет аутентификации, тянуть могут все (pull), заливать (push) — или никто или все. Для постояннодействующих репозиториев надо юзать cgi-шку, которая идет в поставке (hgweb).
Спасибо, нашёл тут пару вариантов как запустить c nginx может ещё кому интерсно будет habrahabr.ru/blogs/personal/90066/ habrahabr.ru/blogs/development_tools/84191/
В статье всё слишком просто. Даже не знаю кому понадобится такой hg serve.
1. Нет нормальной аутентификации.
2. Серв запускается для одного репозитория. Т.е. для одного проекта.

Начал читать маны по поднятию нормального сервера. Вспомнил мучения с mod_dav и mod_dav_fs. Вспомнил как потом радовался выходу коробочного решения VisualSVN Server. Поставил и всё заработало без mod_dav. А теперь чувствую себя так, словно меня откатили назад в прошлое.

TortoiseHg пока тоже слишком далеко до TortoiseSVN. Даже пароль от репо не может запомнить. Приходится каждые 5 минут его набирать при каждом pull/push.

P.S. Всё равно отличный цикл статей. Без них я бы даже не стал возиться с hg. Надеюсь, mercurial разовьётся до уровня SVN, что бы его было приятно использовать.
mercurial.selenic.com/wiki/HgWebDirStepByStep

hgwebdir.cgi работает cgi-шкой под апачем без особых танцев с бубном

Мои настройки апача:

ServerName ДОМЕН
Redirect permanent / ДОМЕН/

ServerName ДОМЕН
ScriptAlias /mysqldump /var/hg/mysqldump.cgi
ScriptAliasMatch ^(.*) /var/hg/hgwebdir.cgi$1

CustomLog /var/hg/log/access.log combined
ErrorLog /var/hg/log/error.log

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem

AuthType Basic
AuthName «Mercurial Server»
AuthUserFile /var/hg/.htpasswd
require valid-user


опять как-то отправилось само… первые две строчки для редиректа с http на https, съелись теги [VirtualHost] и [Location ~ "/.*"] (перед AuthType)
Да. После того как один раз разберёшься, всё кажется совершенно примитивным и очевидным.
TortoiseHG может запомнить пароль (картинка кликабельна), просто по умолчанию этого не делает:



Кстати, делать каждые 5 минут pull/push вроде не совсем в духе Mercurial.
Да действительно всё легко работает.
Ну всё, уговорили. Пересаживаюсь на меркуриал
хотя галки «запомнить пароль» ему всё же не хватает.
А мне гораздо больше bazaar нравится — рекомендую посмотреть
Ой-ой.
Весьма не рекомендую запоминать пароли именно так.
После этого ваш пароль в открытом виде хранится на диске в репозитории.
Правильнее будет в расширениях поставить птичку напротив mercurial_keyring, а на приведенной выше форме указать только имя пользователя.
Тогда тому, кто захочет заполучить ваш пароль прийдется сначала взломать keyring :)
Кстати, интересно, поддерживает ли mercurial_keyring винды. Там же вроде как тоже есть какое-то хранилище юзерских секретов (которым практически никто не пользуется, да)?
Как он устроен внутри — не разбирался. Но под виндой все работает на ура.
под виндой все работает на ура
ну и отлично [х]
hg serve подходит быстрого обмена внутри локалки и только, о чём явно написано в документации. Репозитории типа Bitbucket его, разумеется, не используют — там CGI/WSGI/mod_python. Читайте мануал на сайте Mercurial, всё довольно просто. Можно кстати ещё запустить hg serve с Nginx в режиме прокси и использовать обычную HTTP-аутентификацию.

TortoiseHG прекрасно запоминает пароли, кстати.

mercurial.selenic.com/wiki/PublishingRepositories

P.S. mercurial давно развился до уровня SVN, а во многом и превзошёл. И мануалы надо иногда читать.
я тут попробовал все тортойсы. пользоваться можно только свн-овским и гит-овским. остальные — кривые поделки.
Вопрос к людям с опытом использования меркуриала. Немного смутила фраза
> Никогда и ни за что не используйте ключ -f.
Если я создам отдельную ветку (named branch), то тоже нужен будет ключ -f, чтобы протолкнуть её в основной репозиторий. Что ужасного в таком действии? Как обойтись без этого, если ветка ведется дольше пары-тройки дней? Если ветка ведется более чем одним человеком?
Спасибо, очень познавательно.
Забыл упомянуть, чтобы все заработало без проблем необходим Python 2.6.6
Вот тут можешь посмотреть как настроить сервер для винды под Apache. Это я для себя делал, но может пригодится
Спасибо. Понятные примеры в объяснениях воодушевляют меня исследовать hg дальше!
Жаль, из статьи не видно, что в современных GUI осваивать Mercurial еще проще.

А начинание хорошее у вас.
Что меня сильно смущает (если говорить деликатно) в этих ваших распределенных системах контроля версий, так это то, что каждой из них обязательно надо изобрести свою собственную терминологию, по возможности отличающуюся от централизованных систем, чтобы, не дай боже, не спутали. В результате при чтении статей по Git и Hg вместо «Ага! Вот они те же команды, всё ясно» приходится медитировать на описание процессов и проводить параллели.
В первой части цикла этот момент всколзь затрагивается. Дело в том, что распределенные системы работают не так, как централизованные, потому и терминология другая. Не для всех действий в одной системе есть точное соответствие в другой системе.
не надо проводить параллели, это только вредит пониманию. если hg ещё более-менее смахивает на svn, то git — это вообще другая планета.
а есть скв кроме свн, где каждая директория может использоваться как отдельная репа? и, например, можно одну директорию примержить к другой с сохранением истории.
не, это совсем не то. создавать отдельную репу на каждый модуль — это слишком геморройно. в гите я выкрутился так, что каждый модуль в отдельной ветке одной репы. но как-то это криво.
криво, да. в git же есть submodules.
создай пару десятков реп на гитхабе, а я посмотрю как ты в них будешь копаться.

и частичный чекаут — тоже не то. всё на что он годен — возможность не выкачивать всю репу. при изменении структуры директорий все дружно сосут.
частичный чекаут — тоже не то
ну посмотрите Bazaar — вроде как там частичный чекаут реализован правильно.
Это называется, кажется, partial checkout.
В статье не описано преимущество Hg. SVN в данном случае удобнее, потому как на один шаг меньше.
Отличие Hg от SVN и его преимущества описаны в первой статье из цикла habr.ru/post/108443/
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.