Комментарии 66
НЛО прилетело и опубликовало эту надпись здесь
Есть: TortoiseHg, TortoiseGit.
в TortoiseHg точно можно подключить кастомный diff viewer.
в TortoiseHg точно можно подключить кастомный diff viewer.
+6
Более того, TortoiseHG даже работающий. И сильно упрощает (для меня как виндузятника) процесс ежедневный процесс работы. Особенно радуют иконки у файлов в Проводнике. Точно такие же, как у TortoiseSVN! :)
Для TortoiseGIT придется *отдельно* скачать дистрибутив с прекомпилированным git-ом. А потом *как-то* его подключить к git-у.
Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)
Для TortoiseGIT придется *отдельно* скачать дистрибутив с прекомпилированным git-ом. А потом *как-то* его подключить к git-у.
Вот из-за такого недружественного интерфейса я и остановился на TortoiseHG, который просто работает. :)
+4
mercurial.selenic.com/wiki/MergeProgram
Я помучал под винду парочку, но ничего лучше KDiff3 не нашел.
Внимание, вместе TortoiseHg мне отгрузили старый kdiff3.
Я помучал под винду парочку, но ничего лучше KDiff3 не нашел.
Внимание, вместе TortoiseHg мне отгрузили старый kdiff3.
0
НЛО прилетело и опубликовало эту надпись здесь
Мне TortoiseMerge больше всех нравится — позволяет сразу править отправляемый код во время коммита.
0
Я последнее время на CodeCompare переключился.
Жаль что DiffMerge не обновляется. Юникод бы хотя бы допилили…
Жаль что DiffMerge не обновляется. Юникод бы хотя бы допилили…
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
TortoiseGIT это ок, т.к. по сути это отрихтованный TortoiseSVN.
TortoiseHG не ок, т.к. это собранный из разных кусков аналог. Со своим (gtk'шным вроде бы) гуи и т.д.
TortoiseHG не ок, т.к. это собранный из разных кусков аналог. Со своим (gtk'шным вроде бы) гуи и т.д.
0
Отлично! Ждал второго перевода.
0
Как раз недавно мигрировал с SVN. Колебался между git и hg.
Сначала выбрал git, и TortoiseGit мне понравился, но всё было более-менее хорошо, пока я не стал поднимать общий репозиторий. Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался. Больше всего в git бесит неинформативность сообщений об ошибках. Моё резюме: git только для opensource-анархии.
Решился пожить с Mercurial и обрёл счастье: hg всегда сообщает, что именно не так, и что можно с этим сделать. К тому же механизм ветвлений гораздо прозрачнее. TortoiseHg сильно отличается от идеального TortoiseSVN, но обладает собственной логикой и работает надёжно. Я не сразу понял, что «branch» — понятие сугубо виртуальное, что все «бранчи» хранятся в одном и том же репозитории, и между ними можно легко и быстро переключаться, а Repository Browser позволяет наглядно видеть, что, когда с чем было смешано (merged).
Ещё я пробовал Bazaar, но он нестабилен в развитии и очень уж самобытен. Хотя изначально нравился мне больше всех. Но Hg победил его простотой ветвления (о ветвлении под SVN я даже не знал — там это pain).
В общем, рекомендую Mercurial :-)
Сначала выбрал git, и TortoiseGit мне понравился, но всё было более-менее хорошо, пока я не стал поднимать общий репозиторий. Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался. Больше всего в git бесит неинформативность сообщений об ошибках. Моё резюме: git только для opensource-анархии.
Решился пожить с Mercurial и обрёл счастье: hg всегда сообщает, что именно не так, и что можно с этим сделать. К тому же механизм ветвлений гораздо прозрачнее. TortoiseHg сильно отличается от идеального TortoiseSVN, но обладает собственной логикой и работает надёжно. Я не сразу понял, что «branch» — понятие сугубо виртуальное, что все «бранчи» хранятся в одном и том же репозитории, и между ними можно легко и быстро переключаться, а Repository Browser позволяет наглядно видеть, что, когда с чем было смешано (merged).
Ещё я пробовал Bazaar, но он нестабилен в развитии и очень уж самобытен. Хотя изначально нравился мне больше всех. Но Hg победил его простотой ветвления (о ветвлении под SVN я даже не знал — там это pain).
В общем, рекомендую Mercurial :-)
+6
И да, Спольски я давно читаю и уважаю, поэтому был рад при изучении Mercurial обнаружить hginit.com/ — ресурс очень помог освоить новые для меня подходы к контролю версий. Так что спасибо автору топика за востребованный перевод.
0
НЛО прилетело и опубликовало эту надпись здесь
> Ну оно просто умеет мергать сразу пачку веток
Это как? Другие разве не?
Это как? Другие разве не?
0
НЛО прилетело и опубликовало эту надпись здесь
Невероятная ситуация. Это если между ними нет никакой координации и нет единого центрального репозитория для обмена кодом.
Решается всё очень просто: каждый делает pull + push + pull (контрольный) в центральный репозиторий — и всё обновлено.
Две «головы» — это только для рабочей копии, а веток при этом может быть сколько угодно в одном репозитории. То есть если человек создал себе ветку и выложил её в общий репо, то я её также вытяну без смешивания, могу в неё «заглянуть», а потом вернутся в свою или главную ветку и продолжить работу. А когда пришла пора влить ветку в главную линию разработки в эту самую ветку тягаются изменения из главной, а потом обратно — и всё слито.
Разве не? )
Решается всё очень просто: каждый делает pull + push + pull (контрольный) в центральный репозиторий — и всё обновлено.
Две «головы» — это только для рабочей копии, а веток при этом может быть сколько угодно в одном репозитории. То есть если человек создал себе ветку и выложил её в общий репо, то я её также вытяну без смешивания, могу в неё «заглянуть», а потом вернутся в свою или главную ветку и продолжить работу. А когда пришла пора влить ветку в главную линию разработки в эту самую ветку тягаются изменения из главной, а потом обратно — и всё слито.
Разве не? )
0
НЛО прилетело и опубликовало эту надпись здесь
Проверил, действительно ))
Правда, хватило трёх merge-коммитов:
Но вообще-то я считаю эту логику более верной и целостной — вливать изменения по одному, а не скопом. Так легче отследить природу вещей и получить понятное дерево веток.
Правда, хватило трёх 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
Но вообще-то я считаю эту логику более верной и целостной — вливать изменения по одному, а не скопом. Так легче отследить природу вещей и получить понятное дерево веток.
+1
Вас спасёт rebase
p,s.
Да, я некрофаг -))
p,s.
Да, я некрофаг -))
0
> Оказалось, что поднять закрытый сервер git — это очень нетривиально, потратив несколько часов, я сдался.
Расскажите, с Hg это оказалось проще?
Для Git есть gitk и очень удобный кроссплатформенный SmartGit, они тоже показывают деревья.
Расскажите, с Hg это оказалось проще?
Для Git есть gitk и очень удобный кроссплатформенный SmartGit, они тоже показывают деревья.
0
> Расскажите, с Hg это оказалось проще?
Да, намного. Если ошибаешься, то Hg пишет нормальный текст ошибки в лог с указанием способа её исправить.
Всё быстро настроил через apache+hgweb.cgi.
С git так и не смог разобраться — просто не работает и всё, и никаких тебе ошибок ни в одном логе. Плясал с бубном долго, потом плюнул. В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там.
У tortoisegit, кстати, тоже не всё хорошо, когда требуется вводить логины/пароли при доступе, а вот у tortoisehg всё с этим замечательно. И тут тоже hg гораздо более толково отвечает в случае ошибок.
Да, намного. Если ошибаешься, то Hg пишет нормальный текст ошибки в лог с указанием способа её исправить.
Всё быстро настроил через apache+hgweb.cgi.
С git так и не смог разобраться — просто не работает и всё, и никаких тебе ошибок ни в одном логе. Плясал с бубном долго, потом плюнул. В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там.
У tortoisegit, кстати, тоже не всё хорошо, когда требуется вводить логины/пароли при доступе, а вот у tortoisehg всё с этим замечательно. И тут тоже hg гораздо более толково отвечает в случае ошибок.
0
>> В форумах многие сокрушаются о трудностях в настройке авторизованного доступа к git, но воз и ныне там
Можно использовать тот же прием, что и в SVN с протоколом svn+ssh:
svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
Можно использовать тот же прием, что и в SVN с протоколом svn+ssh:
svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
0
По поводу web-доступа. В TortoiseHG есть встроенный мини-сервер. Для домашних нужд, так сказать. Заводится нажатием на одну кнопку. Ничего стороннего не надо.
0
Если уже работает Apache, зачем плодить сущности?
А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )
А так да — удобно, некоторые разработчики, говорят, по локалке или через интернет с помощью этого встроенного сервера обмениваются обновлениями между репозиториями )
0
Вот только у этого сервера есть одна серьезная проблема — он не поддерживает аутентификацию пользователей.
То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…
То есть чтение и запись в репозиторий можно либо разрешить либо запретить ВСЕМ пользователям. Так что за пределами локальной сети он не применим, да и в локальной довольно небезопасен…
0
Это да. Но *обычно* на венде нету Апача :)
0
Я поднял всё это хозяйство очень просто и быстро даже на обыкновенном shared-хостинге. Это просто как:
Для аутентификации использовался уже существующий .htpasswd.
easy_install mercurial && vim hgwebdir.cgi && vim hgweb.config && vim .htaccess
Для аутентификации использовался уже существующий .htpasswd.
0
Не нравится в hgweb.cgi, что можно настроить права на push, но нельзя на hg pull. Т. е. если на сервере несколько репозиториев с аутентификацией по http(s), то все будут иметь доступ на чтение всех репов.
0
НЛО прилетело и опубликовало эту надпись здесь
Как верно отметил develop7, для Mercurial вообще есть много вариантов.
Что же касается связки с apache, то ничто не мешает вам настроить столько разных hgweb.cgi (со своим конфигом, набором репозиториев и правами доступа) по разным URL, сколько вам нужно. При этом например можно использовать один и тот же или разные .htpasswd, а также для каждого репозитория отдельно настраиваются права доступа в hgrc.
Что же касается связки с apache, то ничто не мешает вам настроить столько разных hgweb.cgi (со своим конфигом, набором репозиториев и правами доступа) по разным URL, сколько вам нужно. При этом например можно использовать один и тот же или разные .htpasswd, а также для каждого репозитория отдельно настраиваются права доступа в hgrc.
0
Лень мешает… сейчас мне для создания репа надо сделать mkdir, hg init, прописать allow_push и всё. Настраивать всё практически заново намного дольше.
Ларчик проще открывался: есть опция allow_read в hgrc, в доках о ней почему-то редко упоминают (не всегда она была видимо). У меня работает. Дока: www.selenic.com/mercurial/hgrc.5.html
Ларчик проще открывался: есть опция allow_read в hgrc, в доках о ней почему-то редко упоминают (не всегда она была видимо). У меня работает. Дока: www.selenic.com/mercurial/hgrc.5.html
+1
Это все конечно хорошо и наверно даже кому-то полезно, но что бы хотелось так это как работать с Hg в реальных проектах — как организовать множество репозиториев для отдельных частей проекта, как организовать деплой на продакшн, как организовать цикл разработки и так далее
А базовая версионность у меня в IDE есть :)
А базовая версионность у меня в IDE есть :)
+1
Всё прекрасно подробно описано в hgbook.red-bean.com/read/
А «с высока» в самом общем виде будет в следующих сериях этого перевода.
А «с высока» в самом общем виде будет в следующих сериях этого перевода.
+1
НЛО прилетело и опубликовало эту надпись здесь
Я правильно понял, что по умолчанию Hg при коммите добавляет все изменённые файлы? Имхо не очень очевидно и удобно.
0
По умолчанию он предлагает сохранить все изменения в уже добавленных в репозиторий файлах. Неизвестные ему файлы он отмечает как неизвестные, их можно добавить в коммит.
+3
В общем-то правильно поняли.
Но речь идет об умолчаниях, при работе из командной строки.
В реальности же вы будете использовать плагины к вашей IDE либо tortoiseHG и там что выберете то и добавит.
Но речь идет об умолчаниях, при работе из командной строки.
В реальности же вы будете использовать плагины к вашей IDE либо tortoiseHG и там что выберете то и добавит.
+1
Можно сделать hg commit файл/каталог, чтобы закомитить только файл/каталог.
+2
Я не очень знаком с тем, как остальные пользуются VCS, но я как-то в Git не привык делать stash, так что бывает после некоторого количества изменений открываю gui, выбираю нужные часть/файлы и делаю отдельные коммиты. В Hg, получается, придётся делать revent, потом коммит первого, а потом остаток. имхо, это не очень последовательно, но это скорее дело вкуса.
0
Более того, из нескольких изменений в одном файле можно комитить только некоторые, а остальные потом «сбросить», сделав revert.
0
прочитал статью — пока никаких отличий от svn, буду ждать описания ветвлений
+2
На самом деле это кусочки одного большого документа, который обретёт смысл тогда, когда будет доступен целиком.
+2
Первая часть, кстати, более информативна, на мой взгляд. А чтобы врубиться в то, как работают ветки, достаточно взять hg и попробовать, прочитав официальный man с вики-страницы проекта — mercurial.selenic.com/wiki/UnderstandingMercurial
+1
Видимо не очень внимательно читал :)
Одно из главных отличий — для использования всех преимуществ системы контроля версий не нужен отдельный сервер. Можно локально на диске создать репозиторий и работать. Или при работе с удаленным репозиторием, при потере связи с сервером можно спокойно работать со своим локальным репозиторием, а когда связь появится, синхронизироваться с удаленным.
В жизни встречается немало ситуаций когда это критично.
Одно из главных отличий — для использования всех преимуществ системы контроля версий не нужен отдельный сервер. Можно локально на диске создать репозиторий и работать. Или при работе с удаленным репозиторием, при потере связи с сервером можно спокойно работать со своим локальным репозиторием, а когда связь появится, синхронизироваться с удаленным.
В жизни встречается немало ситуаций когда это критично.
+1
Одно важное для меня отличие уже есть: Если работаешь один, то репозиторий создаётся прямо в каталоге проекта — не надо думать где его разместить, а потом вспоминать куда засунул, если надо перенести на другую машину.
0
Глупый вопрос, а почему hg? svn для subversion — логика прослеживается, про git и говорить нечего, а тут…
А вообще спасибо и автору, и переводчику. В официальных доках всё как-то запутано, имхо
А вообще спасибо и автору, и переводчику. В официальных доках всё как-то запутано, имхо
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hg Init: Часть 2. Основы Mercurial