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

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

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

Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)
+2
К сожалению выбор корпоративногоо стандарта не в моей компетенции. А дома я труЪ ;)
0
Мне TortoiseMerge больше всех нравится — позволяет сразу править отправляемый код во время коммита.
0
В общем — да.
Но иногда в коммит норовят затисаться косметические правки типа удаления пробелов или переноса строк.
Или отладочные строки, которые забыли удалить, типа вывода значения в дебаг, или закомментированный код.
+1
Из бесплатных — лучше, чем DiffMerge (а смотрел много чего), вряд ли можно найти. Это не просто сравнивалка текста — она понимает контекст (C++/C#/Java) и умеет разрешать конфликты там, где SVN мучается изжогой. И, разумеется, можно править на лету, откатывать изменения поблочно, и т.д.

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

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

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

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

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

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

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

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

я имел в виду что после вот такого
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. Всё.
+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


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

Ага: «не читайте Хабр под рутом» ))
Ну да у меня препарсинг в голове был успешно пройден )
0
> Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался.
Расскажите, с Hg это оказалось проще?

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

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

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

У tortoisegit, кстати, тоже не всё хорошо, когда требуется вводить логины/пароли при доступе, а вот у tortoisehg всё с этим замечательно. И тут тоже hg гораздо более толково отвечает в случае ошибок.
0
Давать человеку доступ к серверу по SSH только ради работы с репозиторием — это бред по-моему.
0
Достаточно одной учётки с шеллом hg-ssh для всех пользователей. Или mercurial-server
0
По поводу web-доступа. В TortoiseHG есть встроенный мини-сервер. Для домашних нужд, так сказать. Заводится нажатием на одну кнопку. Ничего стороннего не надо.
0
Если уже работает Apache, зачем плодить сущности?
А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )
0
Вот только у этого сервера есть одна серьезная проблема — он не поддерживает аутентификацию пользователей.
То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…
0
Зато обычно на винде есть IIS.
Лично у меня под ним поставилось гораздо проще чем под апачем и убунтой. (хотя, может быть это потому что винда мне привычней)
0
Я не заморачивался. Встроенного сервера мне вполне хватило.
0
Я поднял всё это хозяйство очень просто и быстро даже на обыкновенном shared-хостинге. Это просто как:

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

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

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

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

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

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

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

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