Не так давно я обосновывал, что git лучше, чем Mercurial. К сожалению, невозможность увязать LDAP-авторизацию иначе, чем через WebDAV, поставила крест на использовании git. WebDAV оказался непригоден для транзакционных операций с большим числом файлов, репозиторий постоянно приходил в некорректное состояние. Примерно через неделю разборок с WebDAV нам надоело жрать этот кактус и было решено использовать Mercurial.

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

Приятности

  1. По сравнению с SVN лучше практически все: отличная скорость, удобная работа с бранчами.

  2. Никаких проблем интеграции с Trac, все сделано на аналогичном SVN’у уровне

  3. Для одновременной работы с SVN и Mercurial существует отличная утилита hgsvn. Мы ее использовали при импорте истории из SVN, все прошло гладко. В моем домашнем репозитории, правда, возникли мелкие проблемы с распознаванием кодировок, до решения которых пока не дошли руки.

  4. Для Windows существует достаточно приятный TortoiseHg. Лично мне удобнее работать с клиентом командной строки, зато Tortoise обеспечивает удобный интерфейс для просмотра логов. На *nix визуальный показ лога входит в ядро Mercurial и вызывается командой hg view.

  5. Mercurial действительно оказался значительно проще в изучении, чем git.

Потенциальные проблемы

Основная проблемная область при переходе c SVN на Mercurial — работа с бранчами и все что с ней связано. Это очень мощная и полезная функциональность, но при неаккуратном использовании может получиться вот такая лапша:

Mercurial branch spaghetti

На картинке вы видите последствия одного коммита в неправильный бранч и последовавший процесс исправления этих последствий.

Настоятельно рекомендую перед миграцией на Mercurial хотя бы одному члену команды внимательно прочитать документацию. Проблемы в первое время обязательно будут возникать, и кто-то должен уметь их решать. Если вы раньше не работали с распределенными системами контроля версий, то интуиция в решении этих проблем не поможет, нужно будет четкое понимание того, что происходит внутри.

Мелочи, на которые стоит обратить внимание:

  • hg push требует флага -f при создании новой “головы”, даже если вы работаете в рамках давно существующего бранча.

  • После мержа все изменения в рабочей копии должны быть закоммичены в рамках одной транзакции. В ряде ситуаций это бывает очень неудобным. Всегда коммитьте все локальные изменения перед мержем!

Материалы

Вакансии закрыты, спасибо всем откликнувшимся!


В связи с повышением спроса со стороны потенциальных заказчиков, мы объявляем набор веб-разработчиков.

Нас 3 человека, находимся в Тольятти, работаем в области аутсорсинга около 5 лет. Клиенты из США, Канады, Европы. Как фирма не оформлены, планируем сделать это в ближайшем будущем. В данный момент нам нужно еще 2-3 разработчика.

Занимаемся разработкой веб-систем на заказ с использованием наиболее современных технологий. На сегодняшний день — Django и Ruby on Rails.

Основные требования

  • Общий опыт работы от 2-3 лет

  • Опыт веб-разработки, выражающийся в понимании HTTP, HTML, CSS, javascript

  • Владение хотя бы 2-мя высокоуровневыми языками программирования

  • Хороший письменный английский

Приветствуется

  • Python, Ruby

  • SQL

  • Django, Ruby on Rails

  • Опыт работы на *nix-системах

  • Опыт написания юнит-тестов, test-driven development

  • Опыт использования систем управления версиями и багтреккинга (мы используем Mercurial и Trac соответственно).

Условия

Готовы платить 2000 долларов в месяц подходящему нам человеку, который сможет адекватно встроиться в коллектив, и давать результат на уровне среднего по команде. Тем, кто знает и умеет меньше, чем мы, первое время будем платить меньше. Поднимать по мере обучения тоже будем, целевой уровень все те же 2000. Нижняя граница стартовой суммы находится где-то в районе 1400, меньше подходящий нам кандидат, вероятно, не стоит. Валюта оплаты зависит от конкретного проекта, обычно это доллары США.

Работа дома. Организуете свое рабочее место своими силами и за свой счет.

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

Тем не менее, мы ожидаем работы на полную ставку, 40 часов в неделю. Формального учета рабочего времени нет, контроллируем по результатам.

Дополнение

Нужно будет 1-2 раза в неделю встречаться лично, поэтому совсем удаленная работа нам не подойдет, нужно чтобы вы находились в Тольятти или окрестностях.


В качестве первого шага присылайте ваше резюме или портфолио.

Со мной можно связаться по почте (me [собака] alexlebedev.com) или ICQ (160365425).

– Александр Лебедев

« Previous PageNext Page »