Comments 46
Давно еще перевел все проекты с svn на HG на сервис bitbucket. Очень доволен. Сама идеология mercurial очень доставляет.
Такое ощущение, что в этой части несколько развенчан миф об удобстве hg serve по сравнению с поднятием сервера для Git.
А вот отдельная команда hg outgoing Меркуриалу в плюс. Посмотрим, что будет дальше :-)
А вот отдельная команда hg outgoing Меркуриалу в плюс. Посмотрим, что будет дальше :-)
классные статьи, Джоэль молодец, переводчик тоже
поставил ради интереса, довольно удобно
поставил ради интереса, довольно удобно
Хорошо что переводы так часто выходят. Главное — не бросайте на пол пути.
Спасибо.
Вопрос: hg serve достаточно надежён, чтобы жить в «диком интернете»? И как у него с потреблением ресурсов при достаточно долгой работе (месяцами, хотя и с небольшим числом push/poll — 2-3 раза в день) без перезапусков?
Вопрос: 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, что бы его было приятно использовать.
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
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
Да действительно всё легко работает.
Ну всё, уговорили. Пересаживаюсь на меркуриал
хотя галки «запомнить пароль» ему всё же не хватает.
Ну всё, уговорили. Пересаживаюсь на меркуриал
хотя галки «запомнить пароль» ему всё же не хватает.
Ой-ой.
Весьма не рекомендую запоминать пароли именно так.
После этого ваш пароль в открытом виде хранится на диске в репозитории.
Правильнее будет в расширениях поставить птичку напротив mercurial_keyring, а на приведенной выше форме указать только имя пользователя.
Тогда тому, кто захочет заполучить ваш пароль прийдется сначала взломать keyring :)
Весьма не рекомендую запоминать пароли именно так.
После этого ваш пароль в открытом виде хранится на диске в репозитории.
Правильнее будет в расширениях поставить птичку напротив mercurial_keyring, а на приведенной выше форме указать только имя пользователя.
Тогда тому, кто захочет заполучить ваш пароль прийдется сначала взломать keyring :)
hg serve подходит быстрого обмена внутри локалки и только, о чём явно написано в документации. Репозитории типа Bitbucket его, разумеется, не используют — там CGI/WSGI/mod_python. Читайте мануал на сайте Mercurial, всё довольно просто. Можно кстати ещё запустить hg serve с Nginx в режиме прокси и использовать обычную HTTP-аутентификацию.
TortoiseHG прекрасно запоминает пароли, кстати.
mercurial.selenic.com/wiki/PublishingRepositories
P.S. mercurial давно развился до уровня SVN, а во многом и превзошёл. И мануалы надо иногда читать.
TortoiseHG прекрасно запоминает пароли, кстати.
mercurial.selenic.com/wiki/PublishingRepositories
P.S. mercurial давно развился до уровня SVN, а во многом и превзошёл. И мануалы надо иногда читать.
я тут попробовал все тортойсы. пользоваться можно только свн-овским и гит-овским. остальные — кривые поделки.
Вопрос к людям с опытом использования меркуриала. Немного смутила фраза
> Никогда и ни за что не используйте ключ -f.
Если я создам отдельную ветку (named branch), то тоже нужен будет ключ -f, чтобы протолкнуть её в основной репозиторий. Что ужасного в таком действии? Как обойтись без этого, если ветка ведется дольше пары-тройки дней? Если ветка ведется более чем одним человеком?
> Никогда и ни за что не используйте ключ -f.
Если я создам отдельную ветку (named branch), то тоже нужен будет ключ -f, чтобы протолкнуть её в основной репозиторий. Что ужасного в таком действии? Как обойтись без этого, если ветка ведется дольше пары-тройки дней? Если ветка ведется более чем одним человеком?
Сделал у себя вот так Setting up a Mercurial server under IIS7 on Windows Server 2008 R2 на Win7
Спасибо. Понятные примеры в объяснениях воодушевляют меня исследовать hg дальше!
Жаль, из статьи не видно, что в современных GUI осваивать Mercurial еще проще.
А начинание хорошее у вас.
А начинание хорошее у вас.
Что меня сильно смущает (если говорить деликатно) в этих ваших распределенных системах контроля версий, так это то, что каждой из них обязательно надо изобрести свою собственную терминологию, по возможности отличающуюся от централизованных систем, чтобы, не дай боже, не спутали. В результате при чтении статей по Git и Hg вместо «Ага! Вот они те же команды, всё ясно» приходится медитировать на описание процессов и проводить параллели.
а есть скв кроме свн, где каждая директория может использоваться как отдельная репа? и, например, можно одну директорию примержить к другой с сохранением истории.
mercurial.selenic.com/wiki/Subrepository?action=show&redirect=subrepos
По моему это то что вы хотите.
По моему это то что вы хотите.
не, это совсем не то. создавать отдельную репу на каждый модуль — это слишком геморройно. в гите я выкрутился так, что каждый модуль в отдельной ветке одной репы. но как-то это криво.
UFO just landed and posted this here
В статье не описано преимущество Hg. SVN в данном случае удобнее, потому как на один шаг меньше.
Sign up to leave a comment.
Hg Init: Часть 3. Привыкаем работать в команде