Hg Init: Часть 2. Основы Mercurial

[Bobrovsky]

Есть: TortoiseHg, TortoiseGit.

в TortoiseHg точно можно подключить кастомный diff viewer.

[linuxoid]

Более того, TortoiseHG даже работающий. И сильно упрощает (для меня как виндузятника) процесс ежедневный процесс работы. Особенно радуют иконки у файлов в Проводнике. Точно такие же, как у TortoiseSVN! :)

Для TortoiseGIT придется *отдельно* скачать дистрибутив с прекомпилированным git-ом. А потом *как-то* его подключить к git-у.

Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)

[nightstalker]

Вы не оправдываете свой ник ;)

[linuxoid]

К сожалению выбор корпоративногоо стандарта не в моей компетенции. А дома я труЪ ;)

[Hellbot]

mercurial.selenic.com/wiki/MergeProgram

Я помучал под винду парочку, но ничего лучше KDiff3 не нашел.
Внимание, вместе TortoiseHg мне отгрузили старый kdiff3.

[rubyrabbit]

Мне TortoiseMerge больше всех нравится — позволяет сразу править отправляемый код во время коммита.

[Wyrd]

Мне кажется, это плохая идея :)

[rubyrabbit]

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

[pennanth]

Из бесплатных — лучше, чем DiffMerge (а смотрел много чего), вряд ли можно найти. Это не просто сравнивалка текста — она понимает контекст (C++/C#/Java) и умеет разрешать конфликты там, где SVN мучается изжогой. И, разумеется, можно править на лету, откатывать изменения поблочно, и т.д.

[Killy]

Я последнее время на CodeCompare переключился.

Жаль что DiffMerge не обновляется. Юникод бы хотя бы допилили…

[katremer]

TortoiseGIT это ок, т.к. по сути это отрихтованный TortoiseSVN.

TortoiseHG не ок, т.к. это собранный из разных кусков аналог. Со своим (gtk'шным вроде бы) гуи и т.д.

[Zubchick]

Отлично! Ждал второго перевода.

[rubyrabbit]

Как раз недавно мигрировал с SVN. Колебался между git и hg.

Сначала выбрал git, и TortoiseGit мне понравился, но всё было более-менее хорошо, пока я не стал поднимать общий репозиторий. Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался. Больше всего в git бесит неинформативность сообщений об ошибках. Моё резюме: git только для opensource-анархии.

Решился пожить с Mercurial и обрёл счастье: hg всегда сообщает, что именно не так, и что можно с этим сделать. К тому же механизм ветвлений гораздо прозрачнее. TortoiseHg сильно отличается от идеального TortoiseSVN, но обладает собственной логикой и работает надёжно. Я не сразу понял, что «branch» — понятие сугубо виртуальное, что все «бранчи» хранятся в одном и том же репозитории, и между ними можно легко и быстро переключаться, а Repository Browser позволяет наглядно видеть, что, когда с чем было смешано (merged).

Ещё я пробовал Bazaar, но он нестабилен в развитии и очень уж самобытен. Хотя изначально нравился мне больше всех. Но Hg победил его простотой ветвления (о ветвлении под SVN я даже не знал — там это pain).

В общем, рекомендую Mercurial :-)

[rubyrabbit]

И да, Спольски я давно читаю и уважаю, поэтому был рад при изучении Mercurial обнаружить hginit.com/ — ресурс очень помог освоить новые для меня подходы к контролю версий. Так что спасибо автору топика за востребованный перевод.

[rubyrabbit]

> Ну оно просто умеет мергать сразу пачку веток

Это как? Другие разве не?

[rubyrabbit]

Невероятная ситуация. Это если между ними нет никакой координации и нет единого центрального репозитория для обмена кодом.
Решается всё очень просто: каждый делает pull + push + pull (контрольный) в центральный репозиторий — и всё обновлено.
Две «головы» — это только для рабочей копии, а веток при этом может быть сколько угодно в одном репозитории. То есть если человек создал себе ветку и выложил её в общий репо, то я её также вытяну без смешивания, могу в неё «заглянуть», а потом вернутся в свою или главную ветку и продолжить работу. А когда пришла пора влить ветку в главную линию разработки в эту самую ветку тягаются изменения из главной, а потом обратно — и всё слито.
Разве не? )

[rubyrabbit]

Проверил, действительно ))
Правда, хватило трёх merge-коммитов:

[root test]# hg init .
[root test]# for ((i = 0; i < 5; i++)); do touch $i ; hg ci -A -m "commit $i" -u me; hg up -r 0; done
adding 0
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
adding 1
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
adding 2
created new head
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
adding 3
created new head
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
adding 4
created new head
0 files updated, 0 files merged, 1 files removed, 0 files unresolved

[root test]# hg merge
abort: branch 'default' has 4 heads - please merge with an explicit rev
(run 'hg heads .' to see heads)
[root test]# hg merge -r 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
[root test]# hg merge -r 2
abort: outstanding uncommitted merges
[root test]# hg ci -m "Merge" -u me
[root test]# hg merge -r 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
[root test]# hg ci -m "Merge" -u me
[root test]# hg merge -r 3
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
[root test]# hg ci -m "Merge" -u me
[root test]# hg heads
changeset: 7:7730558ebc8b
tag: tip
parent: 6:f7693b67ce1f
parent: 3:e07e55ac1d22
user: me
date: Tue Nov 23 16:36:20 2010 +0300
summary: Merge


Но вообще-то я считаю эту логику более верной и целостной — вливать изменения по одному, а не скопом. Так легче отследить природу вещей и получить понятное дерево веток.

[rubyrabbit]

> кстати это вы зря под рутом сниппеты от незнакомых людей запускаете ;)

Ага: «не читайте Хабр под рутом» ))
Ну да у меня препарсинг в голове был успешно пройден )

[SowingSadness]

Вас спасёт rebase

p,s.
Да, я некрофаг -))

[Sannis]

> Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался.
Расскажите, с Hg это оказалось проще?

Для Git есть gitk и очень удобный кроссплатформенный SmartGit, они тоже показывают деревья.

[rubyrabbit]

> Расскажите, с Hg это оказалось проще?

Да, намного. Если ошибаешься, то Hg пишет нормальный текст ошибки в лог с указанием способа её исправить.
Всё быстро настроил через apache+hgweb.cgi.

С git так и не смог разобраться — просто не работает и всё, и никаких тебе ошибок ни в одном логе. Плясал с бубном долго, потом плюнул. В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там.

У tortoisegit, кстати, тоже не всё хорошо, когда требуется вводить логины/пароли при доступе, а вот у tortoisehg всё с этим замечательно. И тут тоже hg гораздо более толково отвечает в случае ошибок.

[symbix]

>> В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там

Можно использовать тот же прием, что и в SVN с протоколом svn+ssh:
svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks

[rubyrabbit]

Давать человеку доступ к серверу по SSH только ради работы с репозиторием — это бред по-моему.

[linuxoid]

По поводу web-доступа. В TortoiseHG есть встроенный мини-сервер. Для домашних нужд, так сказать. Заводится нажатием на одну кнопку. Ничего стороннего не надо.

[rubyrabbit]

Если уже работает Apache, зачем плодить сущности?
А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )

[BearUA]

Вот только у этого сервера есть одна серьезная проблема — он не поддерживает аутентификацию пользователей.
То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…

[linuxoid]

Это да. Но *обычно* на венде нету Апача :)

[BearUA]

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

[linuxoid]

Я не заморачивался. Встроенного сервера мне вполне хватило.

[m17]

Я поднял всё это хозяйство очень просто и быстро даже на обыкновенном shared-хостинге. Это просто как:

easy_install mercurial && vim hgwebdir.cgi && vim hgweb.config && vim .htaccess

Для аутентификации использовался уже существующий .htpasswd.

[edhell]

Не нравится в hgweb.cgi, что можно настроить права на push, но нельзя на hg pull. Т. е. если на сервере несколько репозиториев с аутентификацией по http(s), то все будут иметь доступ на чтение всех репов.

[rubyrabbit]

Как верно отметил develop7, для Mercurial вообще есть много вариантов.

Что же касается связки с apache, то ничто не мешает вам настроить столько разных hgweb.cgi (со своим конфигом, набором репозиториев и правами доступа) по разным URL, сколько вам нужно. При этом например можно использовать один и тот же или разные .htpasswd, а также для каждого репозитория отдельно настраиваются права доступа в hgrc.

[edhell]

Лень мешает… сейчас мне для создания репа надо сделать mkdir, hg init, прописать allow_push и всё. Настраивать всё практически заново намного дольше.

Ларчик проще открывался: есть опция allow_read в hgrc, в доках о ней почему-то редко упоминают (не всегда она была видимо). У меня работает. Дока: www.selenic.com/mercurial/hgrc.5.html

[rubyrabbit]

Точно.

И вот пусть теперь апологеты git укажут, как нужно плясать, чтобы сделать такую же конфигурацию (с частично запрещённым pull и частично разрешённым push) под git + apache )

[Wott]

Это все конечно хорошо и наверно даже кому-то полезно, но что бы хотелось так это как работать с Hg в реальных проектах — как организовать множество репозиториев для отдельных частей проекта, как организовать деплой на продакшн, как организовать цикл разработки и так далее

А базовая версионность у меня в IDE есть :)

[rubyrabbit]

Всё прекрасно подробно описано в hgbook.red-bean.com/read/
А «с высока» в самом общем виде будет в следующих сериях этого перевода.

[Sannis]

Я правильно понял, что по умолчанию Hg при коммите добавляет все изменённые файлы? Имхо не очень очевидно и удобно.

[rubyrabbit]

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

[BearUA]

В общем-то правильно поняли.
Но речь идет об умолчаниях, при работе из командной строки.
В реальности же вы будете использовать плагины к вашей IDE либо tortoiseHG и там что выберете то и добавит.

[edhell]

Можно сделать hg commit файл/каталог, чтобы закомитить только файл/каталог.

[Sannis]

Я не очень знаком с тем, как остальные пользуются VCS, но я как-то в Git не привык делать stash, так что бывает после некоторого количества изменений открываю gui, выбираю нужные часть/файлы и делаю отдельные коммиты. В Hg, получается, придётся делать revent, потом коммит первого, а потом остаток. имхо, это не очень последовательно, но это скорее дело вкуса.

[Zagrebelion]

Более того, из нескольких изменений в одном файле можно комитить только некоторые, а остальные потом «сбросить», сделав revert.

[Sannis]

Если бы он этого не умел, думаю многие бы выбрали Git ;-)

[MiniM]

прочитал статью — пока никаких отличий от svn, буду ждать описания ветвлений

[rubyrabbit]

На самом деле это кусочки одного большого документа, который обретёт смысл тогда, когда будет доступен целиком.

[elw00d]

Первая часть, кстати, более информативна, на мой взгляд. А чтобы врубиться в то, как работают ветки, достаточно взять hg и попробовать, прочитав официальный man с вики-страницы проекта — mercurial.selenic.com/wiki/UnderstandingMercurial

[BearUA]

Видимо не очень внимательно читал :)
Одно из главных отличий — для использования всех преимуществ системы контроля версий не нужен отдельный сервер. Можно локально на диске создать репозиторий и работать. Или при работе с удаленным репозиторием, при потере связи с сервером можно спокойно работать со своим локальным репозиторием, а когда связь появится, синхронизироваться с удаленным.

В жизни встречается немало ситуаций когда это критично.

[VolCh]

Одно важное для меня отличие уже есть: Если работаешь один, то репозиторий создаётся прямо в каталоге проекта — не надо думать где его разместить, а потом вспоминать куда засунул, если надо перенести на другую машину.

[VolCh]

Глупый вопрос, а почему hg? svn для subversion — логика прослеживается, про git и говорить нечего, а тут…

А вообще спасибо и автору, и переводчику. В официальных доках всё как-то запутано, имхо

[VolCh]

Ну, hydrargyrum — ртуть, это я с школы помню… А причем меркурианский?

[VolCh]

упс, меркурианский — mercurian, а не mercurial — ртутный :)

[rubyrabbit]

Мне тоже не нравится эта путаница.
Пишите hg, называйте «эйчджи» или «хаге», и все вас поймут всё равно ))