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