Такое ощущение, что в этой части несколько развенчан миф об удобстве hg serve по сравнению с поднятием сервера для Git.
А вот отдельная команда hg outgoing Меркуриалу в плюс. Посмотрим, что будет дальше :-)
Вопрос: hg serve достаточно надежён, чтобы жить в «диком интернете»? И как у него с потреблением ресурсов при достаточно долгой работе (месяцами, хотя и с небольшим числом push/poll — 2-3 раза в день) без перезапусков?
У него нет аутентификации, тянуть могут все (pull), заливать (push) — или никто или все. Для постояннодействующих репозиториев надо юзать cgi-шку, которая идет в поставке (hgweb).
В статье всё слишком просто. Даже не знаю кому понадобится такой hg serve.
1. Нет нормальной аутентификации.
2. Серв запускается для одного репозитория. Т.е. для одного проекта.
Начал читать маны по поднятию нормального сервера. Вспомнил мучения с mod_dav и mod_dav_fs. Вспомнил как потом радовался выходу коробочного решения VisualSVN Server. Поставил и всё заработало без mod_dav. А теперь чувствую себя так, словно меня откатили назад в прошлое.
TortoiseHg пока тоже слишком далеко до TortoiseSVN. Даже пароль от репо не может запомнить. Приходится каждые 5 минут его набирать при каждом pull/push.
P.S. Всё равно отличный цикл статей. Без них я бы даже не стал возиться с hg. Надеюсь, mercurial разовьётся до уровня SVN, что бы его было приятно использовать.
Ой-ой.
Весьма не рекомендую запоминать пароли именно так.
После этого ваш пароль в открытом виде хранится на диске в репозитории.
Правильнее будет в расширениях поставить птичку напротив mercurial_keyring, а на приведенной выше форме указать только имя пользователя.
Тогда тому, кто захочет заполучить ваш пароль прийдется сначала взломать keyring :)
hg serve подходит быстрого обмена внутри локалки и только, о чём явно написано в документации. Репозитории типа Bitbucket его, разумеется, не используют — там CGI/WSGI/mod_python. Читайте мануал на сайте Mercurial, всё довольно просто. Можно кстати ещё запустить hg serve с Nginx в режиме прокси и использовать обычную HTTP-аутентификацию.
Вопрос к людям с опытом использования меркуриала. Немного смутила фраза
> Никогда и ни за что не используйте ключ -f.
Если я создам отдельную ветку (named branch), то тоже нужен будет ключ -f, чтобы протолкнуть её в основной репозиторий. Что ужасного в таком действии? Как обойтись без этого, если ветка ведется дольше пары-тройки дней? Если ветка ведется более чем одним человеком?
НЛО прилетело и опубликовало эту надпись здесьНЛО прилетело и опубликовало эту надпись здесь
Что меня сильно смущает (если говорить деликатно) в этих ваших распределенных системах контроля версий, так это то, что каждой из них обязательно надо изобрести свою собственную терминологию, по возможности отличающуюся от централизованных систем, чтобы, не дай боже, не спутали. В результате при чтении статей по Git и Hg вместо «Ага! Вот они те же команды, всё ясно» приходится медитировать на описание процессов и проводить параллели.
В первой части цикла этот момент всколзь затрагивается. Дело в том, что распределенные системы работают не так, как централизованные, потому и терминология другая. Не для всех действий в одной системе есть точное соответствие в другой системе.
а есть скв кроме свн, где каждая директория может использоваться как отдельная репа? и, например, можно одну директорию примержить к другой с сохранением истории.
не, это совсем не то. создавать отдельную репу на каждый модуль — это слишком геморройно. в гите я выкрутился так, что каждый модуль в отдельной ветке одной репы. но как-то это криво.
Hg Init: Часть 3. Привыкаем работать в команде