git vs hg

> нельзя склонировать local->ssh://remote

Чё, в натуре? Тогда бугага.

> отсутствие умолчальных сокращений типа st вместо status

Из командной строки ходовые команды SCM всё равно не используют, а
менее популярные ты всё равно не помнишь и набираешь целиком после
того, как справился в мане.

В Меркуриале самое прикольное это то, что он написан на педошке, так
что хакать и писать к нему расширения весело. А с гитом сплошной
buttseks небось получается. :-(

>> отсутствие умолчальных сокращений типа st вместо status

> Из командной строки ходовые команды SCM всё равно не используют

Говори за себя ;)

> отсутствие умолчальных сокращений типа st вместо status

сокращению нужны только вентузойпам и бздунам латентным (у них баш кривой). Остальные могут использовать аналог sudo aptitude install git-completion

>Из командной строки ходовые команды SCM всё равно не используют

Совсем даже нет. Даже рубирейловцы в скринкастах делают всё в консоле (на маке, естественно).

1. На сервер ставится gitosis и получаем упраление правами для репозиториев плюс удаленный первоначальный пуш. Выглядит это так:

git remote add origin git@git.dev.loc:new_project # Назначаем локальному репозитарию удаленный урл

git push origin master # Отправляем локальный репозитарий на сервер

git config branch.master.remote origin # Назначаем ветку по-умолчанию

git config branch.master.merge refs/heads/master # для git push/pull

2. ХЗ. Что значит кривые?

3. Вот уж нашли проблему. Один раз сделать

git config --global alias.st = status

git config --global alias.co = checkout

git config --global alias.br = branch

git config --global alias.ci = commit

И получаешь удобные тебе алиасы.

4. Что есть то есть. Маны писаны продвинутыми гитерами для продвинутых гитеров, чисто для справки. Но после осваивания http://book.git-scm.com/ -- встроенная справка уже не проблема.

гит не нужон.

>2. ХЗ. Что значит кривые?

http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD vs http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Ну право же. От таких урлов еще никто не умер. Страшненькие, да. Но я лично бы и красивый урл руками не набрал. Максимум это путь к репозитарию (в гите он хорош). А дальше только мышой.

Я по работе сейчас исследую вопрос о переезде на git или hg. Для нашего процесса у hg есть только два преимущества:

1. Хорошая поддержка в IDE

2. Есть плагин для TeamCity

В остальном git намного дружелюбнее для svn пользователей.

И немножко красноглазия:

Кто не пробовал гитовских бранчей во всем их блеске и великолепии, тот и чахнет на своей ртутью.

> В остальном git намного дружелюбнее для svn пользователей.

Какие-то у вас необычные SVN-пользователи.

> Кто не пробовал гитовских бранчей во всем их блеске и великолепии, тот и чахнет на своей ртутью.

Обсуждение этого обычно сводится к "У нас есть такие приборы! Но мы вам о них не расскажем".

>Кто не пробовал гитовских бранчей во всем их блеске и великолепии, тот и чахнет на своей ртутью.

Можно приблизительный воркфлоу? Читать книгу, да?

Я ещё не совсем понимаю, как мне быть в той ситуации, что я один и developer и release team. Валить всё в одну кучу? Или делать clone, разрабатывать в ней некую фичу, потом делать мердж с release.git?

При мердже, наверное, все мои промежуточные правки перейдут в основной репозиторий, что никому не нужно.

А что в них необычного? У svn пользователя есть следующие абстракции при работе с системой контроля версий: репозитарий и бранчи. С бранча можно брать и класть туда код. Также бранчи можно мержить и делать между ними свич. Эти понятия достаточно прозрачно отображаются на гит. Для повседневного использования этого более чем достаточно.

Для меркуриала надо расширять восприятие. Оказываеться есть бранчи, но ими лучше не пользоваться -- есть же невероятно удобные клоны репозитория и пачсеты. Зачем нам свич? Есть же невероятно удобные симлинки и помойка вместо рабочей директории! На первых порах это срывает башню. Я уже представляю нытье и недовольство.

Вобщем я жду что, или в hg появятся нормальные ветки, или в eclipse появится нормальная поддержка git. Плагином для тимсити займусь сам.

> Я ещё не совсем понимаю, как мне быть в той ситуации, что я один и developer и release team. Валить всё в одну кучу? Или делать clone, разрабатывать в ней некую фичу, потом делать мердж с release.git?

Делать бранч в локальном репозитарии и потом git rebase. Подробно здесь http://book.git-scm.com/4_rebasing.html

> А что в них необычного?

Я сам пользователь SVN, который пробовал перейти на git. В результате плюнул на этот ужоснах (правда, это был git около 1.0), и ушел на Mercurial (и ни разу не пожалел).

> бранчи можно мержить и делать между ними свич

Смысл команды switch от меня всегда ускользал.

> Для меркуриала надо расширять восприятие.

Если испольщовать git не в режиме SVN, там тоже нужно нехило расширять сознание. Судя по тому, что я читаю в сети - куда больше, чем для Mercurial.

> Оказываеться есть бранчи, но ими лучше не пользоваться

Да, почему-то постоянная перетензия.

> Есть же невероятно удобные клоны репозитория

Клоны есть и в git, и что?

> и пачсеты.

Я уже не представляю, как без них работать. Кстати, в git есть аналог mq? Про stg и guilt я знаю, а встроенное решение есть?

> Зачем нам свич?

Кстати да - зачем? И что не так с hg co -C?

> Есть же невероятно удобные симлинки и помойка вместо рабочей директории!

Это о чем вообще? O_o

> На первых порах это срывает башню. Я уже представляю нытье и недовольство.

А я - нет. Объяснешь людям, что такое граф версий, и что mq - средство редактирования коммитов, и всё.

>нельзя склонировать local->ssh://remote

Не знаю, что это такое, но для меня git был закрыт после того, как выяснилось, что он не умеет работать с подмонтированными удалёнными FS: sshfs, ftpfs и т.п.

>Не знаю, что это такое, но для меня git был закрыт после того, как выяснилось, что он не умеет работать с подмонтированными удалёнными FS: sshfs, ftpfs и т.п.

А вот это, интересно, зачем нужно? Линус час объясняет, что нужно работать в офлайне. И в этом одно из ключевых достоинств dvcs.

Естественно, что все resource intensive операции, которые Линус странным си кодом реализовывал будут плохо работать по сети (git очень завязан на fs).

Так что это, имхо, как раз несущественный недостаток. Я понимаю, что речь идёт о веб сервисах, но как уже не раз говорилось, отлажиывать на сервере не очень хорошо. Лучше поднять локальный apache+your_favorite_language.

С меркуриалом разбираюсь в течении последнего месяца, поэтому многих тонкостей не знаю. Как реализовать такой процесс:

У каждого разработчика есть директория с кодом всего проекта, на эту диру у каждого настроен локальный веб-сервер. В репозитарии есть несколько фичеветок и стабильный бранч.

Как быстро переключаться между ветками?

git co branch

svn switch branch

hg ? c учетом того, что отдельные ветки это склонированные репозитории

Причем при переключении на другую ветку в гите локальные изменения можно не коммитить а поместить в stash, а потом эти измения снова наложить.

> Не знаю, что это такое, но для меня git был закрыт после того, как выяснилось, что он не умеет работать с подмонтированными удалёнными FS: sshfs, ftpfs и т.п.

Лучшие умы человечества придумывали концепцию dvcs, выделенный процесс деплоя, билд сервера, а суровые славянские парни все равно прикручивают свои странные костыли :)

>А вот это, интересно, зачем нужно?

Для работы с удалённым хостингом на котором, нет никакой DVCS (тогда - sshfs), либо, вообще нет SSH (тогда - ftpfs).

>Линус час объясняет, что нужно работать в офлайне. И в этом одно из ключевых достоинств dvcs.

В офлайне прекрасно работается даже с SVN/CVS :) Речь идёт не о работе в первую очередь, а о выкладывании результатов работы на удалённый сайт. Понятно, что задача не самая распространённая, но для меня - первоприоритетная :)

>но как уже не раз говорилось, отлажиывать на сервере не очень хорошо

А в случае веб-серверов в некоторых случаях отладка возможна _только_ удалённая. Очень распространённая ситуация, когда на тестовой машине всё ок, а на боевой - что-то ломается. Так что ошибка ловится на боевой, а потом исправление можно уже и в репозиторий закоммитить.

>Лучшие умы человечества придумывали концепцию dvcs, выделенный процесс деплоя, билд сервера

Выше описал, зачем это бывает нужно.

>а суровые славянские парни все равно прикручивают свои странные костыли :)

Да нет, никаких костылей, Mercurial такое умеет из коробки :)

>В офлайне прекрасно работается даже с SVN/CVS :)

тебе рассказать про большие коммиты? ;)

>тебе рассказать про большие коммиты? ;)

Это уже другая история :)

...

Кстати, в команде - сборище раздолбаев я всё равно предпочту SVN. Дисциплинирует лучше. Поощряет «работать в онлайне» и делать тонны мелких коммитов. В то время, как с DVCS типичные расп#$дяи будут неделю строчить что-то себе «в стол», потом неделю ликвидировать конфликты и потом вывалят в основной бранч тонну изменений, проследить и потестировать которые нереально, а глюки потом ловить придётся месяцами :)

...

Вот когда в команде люди ответственные и скоординированные - тогда DVCS рулят.

Или, как ни странно, DVCS очень удобна, когда работаешь в одиночку, например, с web-системой, развёрнутой на десятке сайтов. Проще синхронизировать изменения становится.

> Если испольщовать git не в режиме SVN, там тоже нужно нехило расширять сознание. Судя по тому, что я читаю в сети - куда больше, чем для Mercurial

Расширять сознание -- это всегда хорошо, другое дело, когда оно упирается в рубль. В случае с гитом это нужно только CM иженеру/менеджеру. А информацию при желании получить не проблема. Имхо, недавно вышедшая git community book намного позновательнее hg-вики.

> Кстати, в git есть аналог mq? Про stg и guilt я знаю, а встроенное решение есть?

Нет. Надо, кстати, будет попробовать stg. Пока необходимости в таком тонком управлении коммитом не возникало.

> И что не так с hg co -C?

А разве можно сделать чекаут другого репозитария?

> А я - нет. Объяснешь людям, что такое граф версий, и что mq - средство редактирования коммитов, и всё

Насколько я уже пообщался с коллективом, людей сильно волнуют три вопроса:

1. Где будет центральный репозитарий? 2. Обязательно ли делать ветки (после svn тупо боятся) 3. Насколько их потом сложно мержить

Инерция очень сильна. Девелоперы ожидают, что процесс разработки усложнится на порядок.

> У каждого разработчика есть директория с кодом всего проекта, на эту диру у каждого настроен локальный веб-сервер. В репозитарии есть несколько фичеветок и стабильный бранч.

> Как быстро переключаться между ветками?

> hg ? c учетом того, что отдельные ветки это склонированные репозитории

[Хочу сразу сказать, что не использую бранчи, а вместо них пользуюсь отдельными клонированными репозиториями ("branch-per-repo").]

Про "склонированные репозитории" не понял - в каждом из них настрое сервер? Если да, то зачем вообще переключаться между ветками&

Mercurial позволяет держать в одном репозитории много бранчей, и переключаться между ними hg co branch_name, _если_ рабочая копия "чистая". Если в ней есть незафиксированные изменения, которые надо перенести на другой бранч, то так сразу в голову приходит только mq - изменения хранятся как patch queue, и перед hg co делается hg qpop -a, после - hg qpush.

> Причем при переключении на другую ветку в гите локальные изменения можно не коммитить а поместить в stash

В Mercurial тоже. Нужно ли переносить незафиксированные изменения с ветки на ветку?

> Имхо, недавно вышедшая git community book намного позновательнее hg-вики.

Похоже, ты забил на Mercurial довольно давно, так? Еще до выхода Mercurial Book (что само по себе было давно), иначе зачем тебе Wiki? ВотЪ: http://hgbook.red-bean.com/

>> Кстати, в git есть аналог mq? Про stg и guilt я знаю, а встроенное решение есть?

>Нет.

Сакс.

>> И что не так с hg co -C?

> А разве можно сделать чекаут другого репозитария?

Ы? Делаешь hg pull, и другой репозиторий становится частью твоего.

>Насколько я уже пообщался с коллективом, людей сильно волнуют три вопроса:

>1. Где будет центральный репозитарий? 2. Обязательно ли делать ветки (после svn тупо боятся) 3. Насколько их потом сложно мержить

Ну понятно, после опыта с svn switch :) Кстати, ответы на заданные вопросы одинаковы и для git, и для Mercurial.

> Инерция очень сильна. Девелоперы ожидают, что процесс разработки усложнится на порядок.

Думаю, с git так и будет. Он сделан, чтобы идеально подходить стилю работы Линуса, но мало кто так работает.

>> Кстати, в git есть аналог mq? Про stg и guilt я знаю, а встроенное решение есть?

А вот объясните мне, зачем в git с его моделью, вообще нужен mq? Если человек у тебя забирает всё, а потом посылает, грубо говоря, один патч с историей.

А вот то, что в hg нет нормального переименования, это намного более серьёзная проблема. Не говоря о том, что нет таких приятных фич, как история функции, независимо от того из какого файла в какой она переходила.

>В офлайне прекрасно работается даже с SVN/CVS

Только без коммитов.

>о выкладывании результатов работы на удалённый сайт

Зачем там репозиторий-то делать? Экспортировать и всё.

>> Кстати, в git есть аналог mq? Про stg и guilt я знаю, а встроенное решение есть?

> А вот объясните мне, зачем в git с его моделью, вообще нужен mq?

А это точно вопрос ко мне? :) Я ведь не гит-юзер. Может, они волшебным образом перестают делать ошибки в промежуточных коммитах какой-то большой работы. Но я-то их делаю, и мне хочется вернуться назад и исправить их.

> Если человек у тебя забирает всё, а потом посылает, грубо говоря, один патч с историей.

То есть несколько changeset'ов схлопываются в один? O_O Это не "модель git", поверь мне %)

> А вот то, что в hg нет нормального переименования, это намного более серьёзная проблема.

А конкретнее?

> таких приятных фич, как история функции, независимо от того из какого файла в какой она переходила.

Вот чего нет, того нет. Впрочем, меня терзают смутные сомнения :)

> Про "склонированные репозитории" не понял - в каждом из них настрое сервер? Если да, то зачем вообще переключаться между ветками&

Неясно изъяснился. Мне непонятно как из одной диры работать с разными репозитариями, представляющими разные ветки. Как между ними переключаться?

> Нужно ли переносить незафиксированные изменения с ветки на ветку?

Нет. Даже не могу придумать живого примера, когда такое действительно надо

> Делаешь hg pull, и другой репозиторий становится частью твоего

Нужно не частью. Нужна полная замена моего.

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

А вообще, планомерному и глубокому изучению hg очень сильно мешает уже достаточно сносное владение git'ом. Невольно все гитовские приемы пытаешься перенести на меркуриал, а не тут то было. Отсюда весь негатив. Где уж тут объективность? Мне совершенно не хочеться разводить здесь срач.

>То есть несколько changeset'ов схлопываются в один? O_O Это не "модель git", поверь мне %)

Нет. Я так понимаю, ты делаешь бренч new-feature. Допиливаешь её. Потом отсылаешь её в release.git в виде одного коммита. И всё, что было в промежуточных коммитах с ошибками просто не попадает в основную ветку.

Ну так я понял Торвальдса в его выступлении.

>> нет нормального переименования >А конкретнее?

Беру слова назад. Вроде, никаких issues связанных с mv=copy_with_history+delete нет.

> А вот объясните мне, зачем в git с его моделью, вообще нужен mq?

Вообще-то, если поразмыслить, не нужен. Так как есть git rebase --interactive. Вопрос только в удобстве использования. Что меня смущает -- в гите можно сделать абсолютно все, но не всегда простым и очевидным способом. Однако система развивается и уже развернулась к разработчику профилем.

> Если человек у тебя забирает всё, а потом посылает, грубо говоря, один патч с историей.

Большинство, все-таки, работает по модели "отсылают куда-то все изменения с историей"

>Большинство, все-таки, работает по модели "отсылают куда-то все изменения с историей"

А как должен вести себя индивидуальный разработчик? Может быть Mercurial действительно в этой ситуации лучше?

У меня есть mercurial репозиторий. Но наслушавшить Торвальдса подумываю о том, чтоб попробовать git.

>> А вот то, что в hg нет нормального переименования, это намного более серьёзная проблема.

>А конкретнее?

Кстати, с ваших же слов: http://www.linux.org.ru/jump-message.jsp?msgid=2492394&cid=2492466

>> Про "склонированные репозитории" не понял - в каждом из них настрое сервер? Если да, то зачем вообще переключаться между ветками&

>Неясно изъяснился. Мне непонятно как из одной диры работать с разными репозитариями, представляющими разные ветки. Как между ними переключаться?

~/work/branch1 и ~/work/branch2 - клоны одного репозитория, представляющие разные ветки. Переключаться между ними - командой cd ../$branchname. Отличие этой модели от принятой в git - то, что оба бранча существуют в виде рабочих копий одновременно.

>> Делаешь hg pull, и другой репозиторий становится частью твоего

>Нужно не частью. Нужна полная замена моего.

Ы. Тебе нужна полная замена _рабочего каталога_ (aka рабочей копии), но зачем тебе менять _репозиторий_?

На всякий слчай, нанолекция: репозиторий - это, упрощенно говоря, граф ревизий, хранится в .hg; этот граф может содержать уйму вершин, одна из которых служит основой для рабочего каталога; при коммите изменений в граф добавляется новая вершина, содержимым которой является рабочий каталог на момент коммита; вершины грава копируются между репозиториями при hg push/hg pull (в git всё то же самое).

> Если я не понимаю каких-то совершенно базовых вещей

...то ссылку на Mercurial Book я уже давал :)

> с ваших же слов: http://www.linux.org.ru/jump-message.jsp?msgid=2492394&cid=2492466

Ну это мелочь... последствием этой ошибки стало то, что поддержка переименований реализовывалось дольше, чем могло бы, а у скопированных файлов нетривиальная (но вполне объяснимая) семантика merge.

Более серьезная проблема - то, что hg log somedir останавливается на переименовании каталога, приходится указывать еще и имя файла. Впрочем, это может быть всего лишь ошибкой.

> А как должен вести себя индивидуальный разработчик?

Как ему удобно. Это можно решить только исходя из своего опыта. Естественно, сначала можно попытаться применить опыт чужой.

> Но наслушавшить Торвальдса подумываю о том, чтоб попробовать git.

У Линуса свои проблемы и он решает их при помощи гита. Мы же пытаемся приспособить свои проблемы под гит, чтобы он тоже их решал. У кого-то получается у кого-то нет. Проблемы у всех разные.

скажите, а адекватный move есть в меркуриале? не то, что снести один файлы/нарисовать новый, а в один заход, чтобы можно было еще историю смотреть?

>>То есть несколько changeset'ов схлопываются в один? O_O Это не "модель git", поверь мне %)

>Нет. Я так понимаю, ты делаешь бренч new-feature. Допиливаешь её. Потом отсылаешь её в release.git в виде одного коммита.

Это точно не так. После завершения более-менее сложной работы делается pull, который забирает _несколько_ коммитов.

>>Большинство, все-таки, работает по модели "отсылают куда-то все изменения с историей"

>А как должен вести себя индивидуальный разработчик? Может быть Mercurial действительно в этой ситуации лучше?

В этом отношении у Mercurial и git возможности ровно одинаковые.

> наслушавшить Торвальдса подумываю о том, чтоб попробовать git.

Да, пиар у git мощный :)

>Это можно решить только исходя из своего опыта.

Опыт небольшой. Сейчас есть обычная и dev версия. Отлаживаю на одной, потом делаю pull и update на обычной. Один раз хотел сделать эксперементальную фишку, которая потом так и не вошла. Было очень неудобно: решал как-то при помощи branch'ей.

Сейчас подумываю о выкладывании кода с полной реорганизацией структуры каталогов (и даже куски кода будут переезжать). Боюсь,что меркуриал может не справиться.

>> А вот объясните мне, зачем в git с его моделью, вообще нужен mq?

> Вообще-то, если поразмыслить, не нужен. Так как есть git rebase --interactive

Это не то - совсем другой сценарий использования. В Mercurial есть и rebase, и mq.

>скажите, а адекватный move есть в меркуриале? не то, что снести один файлы/нарисовать новый, а в один заход, чтобы можно было еще историю смотреть?

Ну, якобы, при копировании (и последующем удалении) файл сохраняет историю.

> ~/work/branch1 и ~/work/branch2 - клоны одного репозитория, представляющие разные ветки. Переключаться между ними - командой cd ../$branchname.

Вот. Я так себе и представлял этот свитч. То есть директория, на которую настроен апач -- это симлинк на конкретную рабочую копию.

За лекцию, спасибо. На данный момент, для меня, git проще, в плане работы с несколькими равноценными вершинами. Все таки от быстрой навигации по графу отказаться не смогу.

За сим откланиваюсь -- скоро уже четыре утра.

> скажите, а адекватный move есть в меркуриале?

С возвращением из анабиоза тебя! hg mv

>hg mv

rename files; equivalent of copy + remove

>>hg mv

>rename files; equivalent of copy + remove

И что не так? "в один заход, чтобы можно было еще историю смотреть" - всё есть.

>Зачем там репозиторий-то делать?

Потому что в общем случае удалённые правки неизбежны. И хорошо их потом обратно в репозиторий коммитить.

> Потому что в общем случае удалённые правки неизбежны. И хорошо их потом обратно в репозиторий коммитить.

Ну это вообще-то полный звиздец. Помнишь про суровых славянских парней? Обычно в таких случаях, надо откатываться на предыдущую рабочую версию кода, а не судорожно править фаталы (мы же о PHP? Верно?). Максимум, что можно поправить -- это опечатку. Если позволять более серьезные правки -- хаос.

По поводу удаленного дебага -- когда локально проблема не воспроизводится. На нашем проекте распределение такое:

5% случаев -- это различия в конфигурации apache/php.

94% -- не совпадают конфигурации приложения, из них процентов 80 -- используются различные бд (наборы данных, тестовый/продакшен)

1% -- это уже железяки, и бинарники, только в этом случае нужна удаленная отладка.

Но! Удаленная отладка не значит удаленная правка кода! Частота правок на сервере показывает насколько плохо поставлен процесс разработки и тестирования.

Год назад было все плохо -- деплой новой версии был настоящим испытанием. Один человек запускает переключение и смотрит логи, и еще три/четыре разработчика браузят какой-нибудь функционал, чтоб быстрее пользователей наткнуться на исключение или фатал и быстренько его пофиксить. Спасали только специальные dev-урлы с включенным xdebug'ом. Самой частой операцией после деплоя был откат :)

Но даже тогда никто не делал больших правок на сервере, которые сложно повторить локально. Отношение к коду намного ответственнее. Если ты знаешь, что цена правки ошибки достаточно высока, ты лучше локально хорошо протестируешь, и только потом закоммитишь.

Разрешение править на сервере -- это порочная практика, ведет к распиздяйству и неуправляемому коду.

>Обычно в таких случаях, надо откатываться на предыдущую рабочую версию кода, а не судорожно править фаталы

Ты невнимательно читаешь.

В общем случае на тестовой машине не получается достичь 100% аналога чужого удалённого хостинга. И многократно отлаженный локально код при аплоаде способен привести к неработоспособности удалённой системы.

Твои действия?

libastral недоступен by design.

Рассмотрим процентаж :)

>5% случаев -- это различия в конфигурации apache/php.

У меня это процентов 60, наверное, всех ошибок.

>94% -- не совпадают конфигурации приложения, из них процентов 80 -- используются различные бд (наборы данных, тестовый/продакшен)

0%. Не помню ни одной фатальной ошибки с конфигами. Конфиги все раздельные, прямых обращений к БД нигде нет.

>1% -- это уже железяки, и бинарники, только в этом случае нужна удаленная отладка.

Это процентов 30 в моём случае.

Ещё процентов 10 остаётся на фишки, типа «забыл добавить в репозиторий новый класс».

>Но даже тогда никто не делал больших правок на сервере, которые сложно повторить локально.

А кто говорит про сложность локальных повторов? Чаще всего упомянутые ошибки после обнаружения исправляются единичными правками. Но зачем извращаться с раздельным ручным повторением локальной правки (да ещё рискуя что-то забыть - правки на живом сервере нередко делаются быстро, за считанные минуты, чтобы юзеры ничего не заметили :D), когда этим может заняться DVCS?

Согласись, Mercurial не настолько отличатся от git, чтобы потенциальная польза git перевесила лишнюю возню с ручной синхронизацией репозиториев. Компьютер железный - пусть он работает. Так что мне проще набрать лишний раз hg init && hg pull http://... при разворачивании нового проекта.

>Спасали только специальные dev-урлы с включенным xdebug'ом.

Кстати, да. Я ещё _ни разу_ не видел стороннего коммерческого быдлохостинга с наличествующим xdebug :)

Да вы наркоманы штоле? Меркуриал спокон веков умел несколько веток в одном репозитории и переключение между ними по hg update -r <id ревизии>. И базар такое всегда умел, только у него идеология одна ветка - один каталог, хоть и с общим репозиторием, и это правильно, нечего плодить внутри репозитория невидимые сущности, устроили тут windows-way.

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