Никогда, никогда, никогда не накладывайте патчи на используемый софт «на горячую». Пройдёт время, выйдет новая версия софта, вы захотите обновиться, и тут-то вас и настигнут проблемы.
Я сегодня обновлял на работе Review Board, и, разумеется, вспомнил только об одном из пропатченных файлов (а патчил я их, увы, правкой исходников в установленном в site-packages пакете. Хорошо, что старое всё я предварительно забэкапил. Но всё равно искать три изменившихся файла в большом дереве было неприятно.
А выход очень простой. Можно использовать всё, что угодно: можно quilt, можно Mercurial/Git/Bazaar и сделать maintenance-ветку. Я склоняюсь к тому, что лучше всего MQ с версионированием очереди: если от версии к версии патчи существенно поменяются, будет удобная возможность откатиться на предыдущую версию.
Впрочем, мне лично пока хватало MQ без версионирования.
Редакция от 24 февраля 2012
Тэги: hg, работа
Написать комментарий
В дарксе у команды changes есть замечательная опция -s, которая выводит под каждым патчем краткую пофайловую сводку:
[site D:]$ darcs cha --last 1 -s
Fri Mar 4 22:00:52 Russian Standard Time 2011 franoleg@gmail.com
* #436 notify: Support no-auth SMTP sending
M ./help/IndianaSettingsHelp.wiki -1 +5
M ./sendmail.py -7 +16
В меркуриале я такого ничего не нашёл, но по мотивам поста Mercurial: listing files modified in incoming changesets, and guessing conflicts соорудил вот такой батник:
@echo off if .%1.==.. goto USAGE
hg log -r %1 hg log -vr %1 | grep "files:" | sed "s,files:,,"| sed "s,\^[ ]\*,," | tr " " "\012" | sort | uniq goto END
:USAGE echo Usage: %0 REV echo Show hg revision info with file list
:END
Разумеется, требуются unxutils.
Тэги: cmd, darcs, hg
Написать комментарий
Из сегодняшней меркуриальской рассылки узнал о команде hg summary, которая выводит сводку о состоянии репозитория, а с опцией --remote ещё и наличие входящих изменений.
[D|]$ hg summary --remote parent: 5265:6119c843617f К тикету 1544: изменен формат имени папки branch: main commit: 3 modified, 2 added, 14 unknown update: (current) remote: 1 or more incoming
Тэги: hg, советы
Написать комментарий
Мержили на работе две ветки, которые разошлись больше полугода назад. Не без страха, конечно. Это был первый «серьёзный» мерж на меркуриале, а все предыдущие случались ещё под TFS.
Так вот, после ужасного hopebaseless-мержа тоже примерно на полгода разошедшихся веток в TFS я стал слегка нервным. Тогда мы убили уйму времени, а я заимел на TFS зуб.
Меркуриал всё-таки кардинально лучше. Без конфликтов и ошибок, конечно, не обошлось, но давящее ощущение отчаяния к нам больше не придёт.
(Пользуясь случаем, хочу напомнить поклонникам гита: меркуриал и гит — не враги, их общий враг — svn.)
Тэги: hg, tfs, работа
Написать комментарий
Мы тут на работе обсуждали разные системы контроля версий, и в итоге пришли к вот такому сравнению:
Тэги: darcs, hg, svn, работа
Написать комментарий
Для своих проектов я с 2005 года использовал darcs. Эта система контроля версий одновременно гениальна и ужасна. С одной стороны, за четыре года использования даркса для контроля исходников «Индианы» мерж-конфликты у меня были два или три раза. С другой стороны, даркс совсем не подходит для продакшена: нет ни графических обёрток, ни нормальной интеграции в «студию». Даже графической мержилки нет «из коробки»! Теория патчей математически обоснована, а вот про удобство работы для самых разных категорий пользователей никто не подумал. Хотя для маленького самописанного проекта — отлично.
На работе мы сейчас пользуемся TFS, который работает ровно наоборот. Консольный клиент и графический клиент — равные по мощности. Графическая мержилка и возможность подключить любую другую, по выбору. Полная интеграция в «студию».
Но пользоваться этим тяжело. Централизованная система контроля версий — это фэйл. Нет офлайновых коммитов (и вообще работа без сервера затруднена). Все ветки на сервере. При мерже из ветки в транк теряется вся история. Короче, сделать CVS по уму невозможно, Линус был прав.
При этом TFS мне приходилось использовать не только на работе: дома тоже была парочка проектов, где работа шла на TFS-сервере.
В итоге я решил, что надо что-то менять. Осенью прошлого года я, во-первых, поднял на домашнем сервере Trac и начал постепенно обживаться на нём, перенося туда баги и задачи. Во-вторых, я перевёл один свой карманный проект на меркуриал.
Одной из главных причин, почему я выбрал трак, а не один из других багтрекеров, было то, что трак — это комбинированная система управления проектом. Помимо собственно багтрекера, трак содержит модули вики и интеграции с системой контроля версий. Это невероятно удобно и позволяет, к примеру, перейти из режима просмотра коммита по ссылке на связанный тикет с описанием бага.
Трак поддерживает интеграцию с несколькими системами контроля версий, но лучше всего реализована поддержка Subversion и Mercurial. SVN, разумеется, я даже и не рассматривал (он централизованный), а вот меркуриал для моих нужд вполне подошёл.
У меркуриала присутствуют все основные качества распределённой системы версий. Каждая рабочая копия содержит свой репозиторий, система отслеживает патчи, а не версии, мерж веток делается через синхронизацию, история обоих веток сохраняется после мержа.
Кроме того, меркуриал позволяет держать несколько веток в одном репозитории и переключать рабочую копию с одной ветки на другую. Поначалу это непривычно после даркса, но на самом деле очень удобно.
Меркуриал лучше даркса подходит для продакшена. Есть несколько способов сделать центральный репозиторий, куда все коммитят: помимо доступа по SSH, можно прикрутить к веб-серверу hgwebdir или просто пустить крутиться hg serve за nginx с аутентификацией.
Кроме графической оболочки (в винде интегрирующейся с проводником) есть также плагин к «студии», без которого очень грустно было бы объяснять системе, какой файл как переименовали.
Единственной проблемой после выбора хорошей во всех отношениях системы контроля версий было перевести проект, лежащий в TFS, на меркуриал. Для этого я воспользовался двухходовкой: tfs2svn помог мне перегнать проект в SVN, а из SVN в меркуриаловский формат конвертирует команда hg import. И если со второй всё было просто, то конвертация из TFS в SVN попортила мне немало крови.
Сейчас мы на работе идём по тому же пути, по которому я прошёл со своим карманным проектом. (Мержи замучили, да и многим другим параметрам распределённая система просто удобнее.) Но поскольку масштабы у нас побольше, то и проблемы возникают более крупные. В связи с этим я планирую поделиться опытом запинывания tfs2svn, а также выложить патчи к этому конвертеру.
Тэги: darcs, hg, svn, tfs, trac, работа
Написать комментарий