*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

четверг, 21 мая 2009 г.

Какую распределенную систему контроля версий выбрать: Git, Bazaar или Mercurial?

Последние две недели занимаюсь вялотекущим сравнением трех распределенных систем контроля версий: Git, Bazaar и Mercurial.

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

Исторически Git для меня самая родная система, так как пользуюсь ей дольше всего. Поэтому пост будет во многом Git'оцентричный.

С Bazaar познакомился благодаря отличному блогу "Базарный день".

Mercurial пришлось попробовать, так как это православно (причем весьма заслуженно).

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

О колокольне, с которой я смотрю на предмет. Я ищу систему не для дома (собственные проекты у меня сидят на разных системах, и все нормально), а для поддержки системы на нескольких видах UNIX плюс еще и Windows. Примерное количество файлов в ветке проекта около шести тысяч. Объем ~250 мегов (увы, есть некоторое количество двоичных файлов). Объем репозитория особо не волнует, если речь идет о разумных цифрах.

Git

Это скальпель. Время обучения и погружения в систему несколько больше, чем у конкурентов, но более менее приноровившись понимаешь, какой инструмент у тебя в руках. Начинающий пользователь с Git'ом в руках выглядит как ребенок, режущий колбаску хирургическим скальпелем.

Теперь по делу.

Что мне очень нравится в Git — это наличие staging системы (промежуточное звено между рабочими файлами и репозиторием). Очень удобно, когда можно подготовить для комита не весь файл, а только его часть.

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

Очень подкупает невообразимо мощная команда rebase, которой можно сделать с историей проекта все (в том числе и испортить). То есть Git не возводит в религию неприкосновенность истории. Механизм для ее модификации дается, но вот ответственность за результат перекладывается на пользователя. Никто не запретит тебе простым ключиком "--amend" подправить синтаксическую ошибку в тексте последнего комита (да и любого другого комита) или удалить любой комит из истории, но вот надо тебе или нет — вопрос персонального подхода к работе. Из личного опыта как занимающего выпуском релизов скажу, что порой очень нужно иметь возможность менять историю, увы. В Perforce мне из-за этого приходится делать много ручной работы.

Под занавес — есть приятный бонус в виде качественного публичного хостинга github.com.

Из минусов, трогающих меня — это просто омерзительный порт под Windows. Я пользуюсь версией, построенной на MinGW. Пока непобежденным глюком для меня является тот факт, что по какой-то причине некоторые базовые утилиты UNIX, входящие в состав дистрибутива Git под Windows, при старте пытаются, видимо, определить наличие всех логических дисков (C:, D: и т.д.) в системе. Хорошо, когда нет сетевых дисков, а вот когда они есть, то такой опрос занимает раздражающие 2-3 секунды при каждом запуске (причина была выявлена путем анализа сетевого трафика, так как сначала я думал, что у меня вирус). На домашнем компьютере все отлично — там нет сетевых дисков.

Но несмотря на все препоны, с помощью git-p4 я наладил для некоторых наших разработчиков, работающих часто в офлайне, неплохой механизм интеграции с централизованным Perforce. Человек синхронизируется, будучи онлайн, и обновляет локальный репозиторий Git. Потом спокойно работает в офлайне через Git, а затем опять в онлайне засылает все сделанное из Git в Perforce.

Bazaar

Классная система. Работает с полоборота из коробки, но только там, где есть Питон, поэтому на некоторых наших вынужденных UNIXах меня ждал облом.

Пока я не нашел особых смысловых изъянов, мешающих мне работать.

Очень мне нравится подход, когда каждая ветка как таковая живет в отдельном каталоге, то есть имеет свой набор рабочих файлов (хотя может и не иметь).

Как-то с ходу не нашел бесплатного хостинга для Bazaar.

Mercurial

Снова Питон, поэтому автоматически все шоколадно на системах, где он есть, но грустно, где его нет.

Из хороших бонусов есть факт, что Google сделал поддержку хостинга для этой системы. Как написано в их отчете о том, почему они выбрали именно Mercurial, а не Git, как я понял, говорится, что основные причины в более простой интеграции Mercurial в систему http-сервисов (Git тоже умеет через http, но медленнее), и логическая близость синтаксиса команд Mercurial к Subversion (тут, конечно, Git ой как далеко).
В целом, для себя я решил пока так: если для дома для семьи или там где Windows да Linux, то это без сомнения Bazaar или Mercurial (можно монетку подкинуть), а вот все-таки для применения на множестве разнородных систем и там где надо уметь управлять историей, то пока Git.

воскресенье, 17 мая 2009 г.

Список процессов в Windows

Писал я как-то один QA тест, и нужно мне было понять — выполнятся ли сейчас определенный процесс или нет, и если да, то с какой командной строкой. Естественно, нужно и для UNIX и для Windows.

В UNIX в порядке вещей просто вызвать команду ps через popen() и распарсить текстовый вывод. Переносимо и надежно, так как для всех UNIXов ps всегда существует, и на этот факт можно положиться.

Для Windows же все оказалось чуть сложнее. Известная утилита pslist не является стандартной, и полагаться на нее опасно. Возиться с Windows API тоже не хотелось.

Я нашел вот такой способ. Через _popen() (аналог UNIXового popen()) можно вызвать вот такую команду:
WMIC PROCESS get Caption,Commandline,Processid
Получаем название процесса, командную строку и идентификатор процесса.

Конечно, не так задорно, как через ps, но зато стандартно.

Стратегии выпуска релизов

Как мне кажется, в нынешнем мире программного обеспечения появилась доминирующая политика выпуска релизов/версий продукта. Эта политика основана не на факте появления новых возможностей или исправления ошибок, а просто на временных интервалах. А новые возможности и исправления ошибок просто вписываются в график релизов. То есть фраза «когда выйдет новая версия, то мы…» трансформируется в «когда такого-то числа выйдет следующая версия, то мы…».

Данный подход удобен всем. Разработчики в этом случае могу спокойно планировать свои спринты, распределяя по ним план развития продукта, а клиенты могут посмотреть на план этот развития (например, мы его публикуем на сайте поддержки) и понять, что и когда им ждать. Их планирование также упрощается.

Есть тут небольшая загвоздка – это исправление ошибок. Оценить время исправления коварного бага порой не так просто. Хорошо, что такие случаи, скорее всего исключения, так как если они становятся правилом, то возникает вопрос просто о качестве софта в целом.

Мы выпускаем релизы каждый месяц. Мне, как так называемому branch owner’у (я не очень люблю использовать английские слова, но вот «ответственный за версию» как-то уж очень коряво звучит), гораздо проще составлять списки патчей для включения в релиз и планировать окна тестирования, когда дата выпуска всегда постоянна. Конечно, интервал релизов подобран так, чтобы не приходилось выпускать пустые релизы без каких-либо патчей.

И каковы ваши наблюдения на этот счет?

Дж. Ханк Рейнвотер, "Наставление для программистов, руководящих другими программистами"

Дж. Ханк Рейнвотер

Наставление для программистов, руководящих другими программистами



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

Ее многие рекомендуют, поэтому я ее купил. Если честно, я мусолил ее несколько месяцев урывками (недавно добил таки). Крайне тяжелый и корявый язык (может это просто проблема плохого перевода?), читается поэтому очень муторно. Повсюду цитаты, повторяющиеся в самом тексте, что сбивает напрочь ход мысли. Порой автор говорит какую-то очевидную банальщину типа:
Техническое лидерство взращивается на почве знания и питается готовностью учиться на собственных ошибках — в конечном итоге какая практика обязательно увенчается успехом.
Можно заменить "техническое лидерство" на программирование, учебу, игру в шахматы или гольф и суть высказывания не изменится. Тогда о чем все этом?

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


Посты по теме:

Том Демарко, Тимати Листер, "Человеский фактор: успешные проекты и команды"

Том Демарко, Тимати Листер

Человеский фактор: успешные проекты и команды



Вы недавно помимо просто написания кода начали заниматься управлением командой?

Значит пока включить в свой книжный рацион раздел по управлению. И это одна из первых книг. Я прочитал ее не отрываясь за два вечера. Очень легко и понятно написано. Так как управление — это не программирование, и тут нельзя дать четкий рецепт "делай раз, делай два", поэтому книги такого рода стоит рассматривать как повод для размызшлений о том, о чем вы, будучи просто программистом, никогда раньше не думали.

Вывод: Прочитал и поставил на близкую рабочую полку по соседству с Макконнеллом и Бруксом.


Посты по теме:

Travis Swicegood, "Pragmatic Version Control using Git"

Travis Swicegood

Pragmatic Version Control using Git



Хорошее введение в распределенную систему контроля версий Git от сообщества разработчиков ядра Линукса и от Линуса Торвальдса в частности.

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

На официальном сайте есть превосходная электронная живая книга по Git. Многие главы имеют дельные коротенькие видео уроки.

Вывод: обычно я не храню книги "для начинающих", так как после них ты либо никогда предметом не интересуешься, либо копаешь глубже и знания для начинающих становятся очевидными. Но эту я оставлю.

P.S. Для интересующихся распределенными системами контроля версий рекомендую отличный блог про альтернативую систему Bazaar "Базарный день". Прочтете несколько постов и будете готовы использовать Bazaar.

Как вы пишете в Blogspot?

Лично я считаю, что Blogspot имеет радикально неудобный интерфейс для ввода и тем более последующего редактирования постов. Полное “сведение” поста в нем — это кошмар. Сначала ты пишешь основной текст в Ворде, затем вставляешь исходники, если нужно, и потом начинается длительное ёрзанье в html для придания посту правильного вида в браузере.

Так как предварительный просмотр поста в Blogspot не дает полной картины, то единственный способ проверить вид поста, это его, собственно, запостить. Но кому охота выкладывать недоделанный пост? Итерация правки поста крайне неудобна и медленна — цикл “правка –> просмотр –> постинг –> ошибка –> правка –> ...” очень коряв.

После некоторого времени использования Blogspot я пришел вот к такой схеме.

Для начала, нужен таки блог-клиент, как бы этого не хотелось. Тут тебе и вордовая проверка текста встроена, и preview какой никакой есть, и сохранение черновика и много прочих мелких радостей. Перебрав Semagic, BlogJet, несколько клиентов на Яве и придя от всего увиденного в ужас, а остановился, как ни странно на Microsoft Live Writer. Бесплатный (чудо для продукта от Microsoft), понимает Blogspot, много плагинов и встроенная вордовая проверка текста (то есть можно сразу в нем писать). В целом, почти все хорошо.

Но как бы не был хорош preview блог-клиента, единственный способ полностью проверить верстку в Blogspot — это запостить. Для этого можно завести еще один блог, тестовый, который должен быть точной копией основного блога в плане стилей и макета страницы. Теперь можно спокойно постить черновик в тестовый блог и отлаживать верстку окончательно. Причем цикл отладки выглядит так: редактирование в блог-клиента -> постинг в тестовый блог -> refresh страницы в браузере. Гораздо быстрее чем была, так как надо просто переключаться между окнами.

В конце отлаженный пост переносится в основной блог просто копированием html-кода.

понедельник, 11 мая 2009 г.

Табуляция

Символы табуляции в исходниках — это бесконечное зло. А зло в квадрате, когда табуляция используется не только для отступов слева, но как разделитель (например, между аргументами функций, в теле блоков комментариев и т.д.). Ничего, кроме криков из другого конца комнаты типа "какая б... опять дописала кусок в моем неприкосновенном исходнике на С в Эклипсе, используя пробелы вместо табов, так что у меня тут в vi съехали все отступы?". И тут оба неправы. Первый в том, что не использовал тип отступов, принятый уже в существующем документе, а второй — в том, что использовал табуляцию изначально. Все шоколадно и солнечно, когда все сидят в Студии, но когда один использует vi, другой Студию, третий - FAR и т.д. (а это, увы, реалии много-платформенной разработки), то невозможно, чтобы все следовали правилу. Никто не любит соблюдать неудобные правила.

Лично я очень спокоен на тему стиля в целом и длины отступов в частности (лишь бы выглядело читабельно и соответствовало принятому для проекта соглашению), но вот табуляция — это как красная тряпка.

Ситуация усугубляется тем, что мы сопровождаем много кода, которому более двадцати лет, а тогда табуляция была еще ой как в ходу. Вот и приходится уговаривать людей проводить централизованные периодические зачистки кода от мусора прошлых лет, так как нет ничего хуже, когда человек совмещает смысловой коммит с "небольшими стилистическими правками", типа удаления табуляций, разбиения длинных строк и т.д. В целом, в этом не ничего плохого, но после таких "небольших правок" слияние веток становится кошмаром.

понедельник, 4 мая 2009 г.

Автоматизация сборки продукта

Лично я убежден на 100%, что сборка более менее серьезного по размерам проекта/продукта должна производиться в командной строке, то есть никаких GUI-сред, в которые надо заходить, нажимать кнопки, смотреть в окна результатов и т.д. Все это здорово на этапе собственно написания кода, тестирования и отладки. Но когда код переходит в стадию “почти закончен”, все должно заканчиваться полностью авторизированной сборкой без вариантов “тут надо кликнуть, тут надо ввести путь, тут надо сделать clean-up и refresh, а то все съедет” и т.д. Прелесть командной строки в том, что вне зависимости с какого ты сегодня будуна, и что твоя голова с утра проходит в дверь только боком, ты набираешь “cd /my/super/project” и затем “make”. После этого ты откидываешься на стул в мыслях о пивасике, а проект тем временем собирается и тестируется. В идеале, конечно, вместо компиляции, ты должен просто скачать свежую автоматизированную ночную сборку, которая уже там, оттестирована и готова к употреблению.

Ладно, это была всем очевидная лирика.

Наш софт представляет собой монструозный симбиоз из С, С++, Java, BASIC (это наш собственный внутренний СУБД-ориентированный язык), Python’а и UNIX-скриптов. Система же сборки основана на GNU Make и по сути является огромным многоуровневым Makefile’ом. Необходимая при сборке логика, которую нельзя реализовать напрямую в GNU Make дополняется UNIX-скриптами и мини утилитками на C, которые компилируются прямо перед запуском. Java части используют Ant. Плагин Ivy используется для подкачки из репозитория двоичных модулей. Лично я против каких-либо двоичных файлов в проекте, и считаю, что в разы удобнее все компилировать из текстового представления (пусть это и дольше по времени), так как текстовики можно сравнивать, в них можно искать и т.д. Конечно, реальная жизнь сложнее, и иногда приходится использовать заранее собранные бинарники (например, OpenSSL, ICU, тучу сторонних jar’ов для Java и т.д.).

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

Я пытался все перевести на Ant – возможностей много, но все крайне Ява-центричное, расширения надо тоже писать на ней же. Если мы все писали бы на Java, но у нас не тот случай.

Пробовал CMake. Очень неплохо, но обнаружились сложности скрещения с нашим собственным компилятором Бейсика.

Пробовал SCons. Пожалуй, это самая прикольная система. Недаром ее используют в Гугле для реально нетривиальных проектов типа Chrome и Native Client и т.д. По сути Makefile – это программа на Питоне, то есть ограничения на особую логику сборки (запуск тестов, фильтров, сборка документации, публикация результатов на FTP и т.д.) просто отсутствуют. Нужное просто пишется на полноценном языке программирования Питон. Удалось мне даже собрать нормально Питон для AIX и HPUX (с Windows, Linux, Solaris проблем нет вообще). Но и тут получилась ложна гов... дегтя. У меня есть необходимость конвертировать тысячи отчетов по тестам в формат jUnit. Мини утилитка на С, которая писалась на коленке, делает это менее чем за секунду. Все мои попытки на Питоне работали минуты. Получается, что идея опять не чиста, так как нужны опять сопровождающие утилиты, и уже не ясно, зачем что-то менять как оно есть сейчас.

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

 

Посты по теме: