Есть для git'a & Mercurial'a нечто наподобии TortoiseSVN? Можно ли подключать кастомный diff viewer & merge editor?
Есть: TortoiseHg, TortoiseGit.

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

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

Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)
Вы не оправдываете свой ник ;)
К сожалению выбор корпоративногоо стандарта не в моей компетенции. А дома я труЪ ;)
mercurial.selenic.com/wiki/MergeProgram

Я помучал под винду парочку, но ничего лучше KDiff3 не нашел.
Внимание, вместе TortoiseHg мне отгрузили старый kdiff3.
По мне так Araxis Merge самый удобный инструмент. Правда, платный.
Мне TortoiseMerge больше всех нравится — позволяет сразу править отправляемый код во время коммита.
Мне кажется, это плохая идея :)
В общем — да.
Но иногда в коммит норовят затисаться косметические правки типа удаления пробелов или переноса строк.
Или отладочные строки, которые забыли удалить, типа вывода значения в дебаг, или закомментированный код.
Из бесплатных — лучше, чем DiffMerge (а смотрел много чего), вряд ли можно найти. Это не просто сравнивалка текста — она понимает контекст (C++/C#/Java) и умеет разрешать конфликты там, где SVN мучается изжогой. И, разумеется, можно править на лету, откатывать изменения поблочно, и т.д.

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

Жаль что DiffMerge не обновляется. Юникод бы хотя бы допилили…
1) есть.
2) можно.
наподобие
TortoiseGIT это ок, т.к. по сути это отрихтованный TortoiseSVN.

TortoiseHG не ок, т.к. это собранный из разных кусков аналог. Со своим (gtk'шным вроде бы) гуи и т.д.
TortoiseHG не ок
да плевать. главное, что оно 1) есть под Linux и 2) умеет коммитить файло кусками, что позволяет не использовать record extension и CLI
Отлично! Ждал второго перевода.
Как раз недавно мигрировал с SVN. Колебался между git и hg.

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

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

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

В общем, рекомендую Mercurial :-)
И да, Спольски я давно читаю и уважаю, поэтому был рад при изучении Mercurial обнаружить hginit.com/ — ресурс очень помог освоить новые для меня подходы к контролю версий. Так что спасибо автору топика за востребованный перевод.
Моё резюме: git только для opensource-анархии.
Ну оно просто умеет мергать сразу пачку веток, поэтому в ядре Linux без него никак.
Сейчас в топик придут адепты Git и объяснят, что кактус принято есть левой рукой (желательно чужой, желательно свежей), загримировавшись под Джокера верхом на одноглазой гигантской крысе пёстрой масти в ошейнике из сплава 10 редкоземельных элементов и желательно нестабильного изотопа тория, напевая гимн СССР в тональности ля-диез минор вы его неправильно готовите.
> Ну оно просто умеет мергать сразу пачку веток

Это как? Другие разве не?
За другие не скажу, но конкретно mercurial умеет мергать только две «головы» за раз. Соответственно, если
1) в проекте 200 контрибьюторов, и
2) каждый из них сделал по коммиту, не оглядываясь на коллег,
то перед выпиныванием обновок им всем придётся сделать 200 merge commits (в сумме, не каждому — на лицо выйдет по одному-два). Впрочем, возможны и другие варианты (rebase/transplant, кажется; или отдельный репозиторий для сборки релиза, в который обновки выкладываются по hg unbundle — я тут не особо копенгаген).
Невероятная ситуация. Это если между ними нет никакой координации и нет единого центрального репозитория для обмена кодом.
Решается всё очень просто: каждый делает pull + push + pull (контрольный) в центральный репозиторий — и всё обновлено.
Две «головы» — это только для рабочей копии, а веток при этом может быть сколько угодно в одном репозитории. То есть если человек создал себе ветку и выложил её в общий репо, то я её также вытяну без смешивания, могу в неё «заглянуть», а потом вернутся в свою или главную ветку и продолжить работу. А когда пришла пора влить ветку в главную линию разработки в эту самую ветку тягаются изменения из главной, а потом обратно — и всё слито.
Разве не? )
всё так. естественно, это синтетический пример и такого в жизни не бывает.

я имел в виду что после вот такого
for ((i = 0; i < 5; i++)); do touch $i ; hg ci -A -m "commit $i"; hg up -r 0; done
в случае с mercurial понадобится 4 merge commits, тогда как в случае с git — 1. Всё.
Проверил, действительно ))
Правда, хватило трёх 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


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

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

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

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

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

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

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

Можно использовать тот же прием, что и в SVN с протоколом svn+ssh:
svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
Давать человеку доступ к серверу по SSH только ради работы с репозиторием — это бред по-моему.
Достаточно одной учётки с шеллом hg-ssh для всех пользователей. Или mercurial-server
По поводу web-доступа. В TortoiseHG есть встроенный мини-сервер. Для домашних нужд, так сказать. Заводится нажатием на одну кнопку. Ничего стороннего не надо.
Если уже работает Apache, зачем плодить сущности?
А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )
Вот только у этого сервера есть одна серьезная проблема — он не поддерживает аутентификацию пользователей.
То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…
Это да. Но *обычно* на венде нету Апача :)
Зато обычно на винде есть IIS.
Лично у меня под ним поставилось гораздо проще чем под апачем и убунтой. (хотя, может быть это потому что винда мне привычней)
Я не заморачивался. Встроенного сервера мне вполне хватило.
Я поднял всё это хозяйство очень просто и быстро даже на обыкновенном shared-хостинге. Это просто как:

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

Для аутентификации использовался уже существующий .htpasswd.
Не нравится в hgweb.cgi, что можно настроить права на push, но нельзя на hg pull. Т. е. если на сервере несколько репозиториев с аутентификацией по http(s), то все будут иметь доступ на чтение всех репов.
Я, к слову, предпочитаю mercurial-server. Есть в репозиториях, легко настраивается, очень гибкий. Крайне доволен.
Как верно отметил develop7, для Mercurial вообще есть много вариантов.

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

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

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

А базовая версионность у меня в IDE есть :)
Всё прекрасно подробно описано в hgbook.red-bean.com/read/
А «с высока» в самом общем виде будет в следующих сериях этого перевода.
организовать множество репозиториев для отдельных частей проекта
mercurial.selenic.com/wiki/Subrepository
как организовать деплой на продакшн
capistrano поддерживает в том числе и mercurial
как организовать цикл разработки
mercurial.selenic.com/wiki/MultipleCommitters и mercurial.selenic.com/wiki/WorkingPractices
Я правильно понял, что по умолчанию Hg при коммите добавляет все изменённые файлы? Имхо не очень очевидно и удобно.
По умолчанию он предлагает сохранить все изменения в уже добавленных в репозиторий файлах. Неизвестные ему файлы он отмечает как неизвестные, их можно добавить в коммит.
В общем-то правильно поняли.
Но речь идет об умолчаниях, при работе из командной строки.
В реальности же вы будете использовать плагины к вашей IDE либо tortoiseHG и там что выберете то и добавит.
Можно сделать hg commit файл/каталог, чтобы закомитить только файл/каталог.
Я не очень знаком с тем, как остальные пользуются VCS, но я как-то в Git не привык делать stash, так что бывает после некоторого количества изменений открываю gui, выбираю нужные часть/файлы и делаю отдельные коммиты. В Hg, получается, придётся делать revent, потом коммит первого, а потом остаток. имхо, это не очень последовательно, но это скорее дело вкуса.
ну я в hgtk (tortoisehg) аналогично выбираю какие файлы/куски файлов коммитить. и опять-таки — команде hg commit можно явно сказать «коммитим это, это, это и вот эти два каталога».
Более того, из нескольких изменений в одном файле можно комитить только некоторые, а остальные потом «сбросить», сделав revert.
Если бы он этого не умел, думаю многие бы выбрали Git ;-)
прочитал статью — пока никаких отличий от svn, буду ждать описания ветвлений
На самом деле это кусочки одного большого документа, который обретёт смысл тогда, когда будет доступен целиком.
Первая часть, кстати, более информативна, на мой взгляд. А чтобы врубиться в то, как работают ветки, достаточно взять hg и попробовать, прочитав официальный man с вики-страницы проекта — mercurial.selenic.com/wiki/UnderstandingMercurial
Видимо не очень внимательно читал :)
Одно из главных отличий — для использования всех преимуществ системы контроля версий не нужен отдельный сервер. Можно локально на диске создать репозиторий и работать. Или при работе с удаленным репозиторием, при потере связи с сервером можно спокойно работать со своим локальным репозиторием, а когда связь появится, синхронизироваться с удаленным.

В жизни встречается немало ситуаций когда это критично.
Одно важное для меня отличие уже есть: Если работаешь один, то репозиторий создаётся прямо в каталоге проекта — не надо думать где его разместить, а потом вспоминать куда засунул, если надо перенести на другую машину.
Глупый вопрос, а почему hg? svn для subversion — логика прослеживается, про git и говорить нечего, а тут…

А вообще спасибо и автору, и переводчику. В официальных доках всё как-то запутано, имхо
первая картинка намекает
Ну, hydrargyrum — ртуть, это я с школы помню… А причем меркурианский?
упс, меркурианский — mercurian, а не mercurial — ртутный :)
Мне тоже не нравится эта путаница.
Пишите hg, называйте «эйчджи» или «хаге», и все вас поймут всё равно ))
Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.