О важности CM

На проводе Stephen Nuchia, Founder at J-BIRD Search and Rescue:

A childhood friend of mine was killed fighting a fire in 2001 and I just recently read the official report on his death. Poor CM turns our to have been one of the three mistakes that killed him. The maintenance procedures being used for his breathing apparatus didn't match the model of equipment issued. Does CM matter? It does to me.

via LinkedIn

Статья про слияние изменений (merge)

Набрёл сегодня на небольшую статью под названием "Who’s afraid of the big bad merge?" ("Кто боится большого и страшного Мёржа?") Речь идет о слиянии (merge) исходников между ветками по время параллельной разработки.

Из вступления:
In this post I will take a look at some of the issues that arise from managing parallel development and, perhaps more importantly, provide some guidance on how to avoid the pitfalls of parallel development.
что означает примерно следующее: "О некоторых проблемах параллельной разработки и о том, как с ними бороться."

Картинка для привлечения внимания:

Итак, Часть 1 , часть 2. После каждой части - подзаголовок Mitigation, именно там показывается, как можно смягчить показаные проблемы.

Советы толковые. Во время работы в Мотороле приходилось сталкиваться почти со всеми описанными случаями. Но поставленный процесс и супер-инструмент IBM Rational Clearcase сводили на нет все попытки Полярного Зверька забороть нас.


via CMCrossroads

И снова о RSDN Magazine #3

Пару слов в продолжение записи о RSDN Magazine #3.
Статью разместили в онлайне:
http://www.rsdn.ru/article/Methodologies/CM_basics_part2.xml

Причем там присутствует фрагмент с развернутым примером про отращивание веток и их слияние.

Приятного чтения.

P.S. Вот обложка, кстати. Увидите - берите два ;)

RSDN Magazine #3 2009

В свет вышел RSDN Magazine за номером 3, год выпуска - 2009.
При чем здесь записки СМщика? Там опубликовано продолжение (оно же завершение) первой статьи об основах СМ. К сожалению, статью урезали, чтобы уложить в объем журнала. Остался за бортом развернутый пример с отращиванием веток и рисованием стрелочек слияния. Кому интересно - он есть в статье про контроль версий.

Что интересно, на RSDN пока ничего про него не было - ни новостей, ни анонсов. В онлайне целиком опубликуют, видимо, нескоро. В любом случае, весь материал статей уже опубликован здесь, в блоге.

P.S. Теперь я писатель-рецидивист.

DVCS // Пример CM-политики с использованием git

Через известный ресурс набрёл на описание политики управления конфигурацией в рамках проекта с использованием git.

Собственно, сама заметка.

При всём моём неприятии git и распределенной модели... :) Раз уж их используете - то хоть используйте правильно и эффективно, как показано в заметке.

P.S. Ну и набор ссылок по теме:
http://scm-notes.blogspot.com/2009/11/ms-tfs-branching-guidance.html - о ветвлении и работе с контролем версий в Team Foundation Server
http://scm-notes.blogspot.com/2009/10/software-configuration-management-6.html - о распределенных системах контроля версий
http://www.cmcrossroads.com/bradapp/acme/branching/ - всеобъемлющая статья из серий "basics" и одновременно "essentials" на уважаемом ресурсе.
http://www.infoq.com/articles/agile-version-control  - о контроле версий в стиле agile.

Gource // визуализация контроля версий

Проект дня — Gource.

Берёт на вход логи проекта из git, а также SVN, CVS, Mercurial (после конвертации) и растит в реальном времени дерево — как развивался проект, как появлялись элементы, и их версии.

Одно из видео проекта. Там их несколько.



Enjoy.

MS TFS // Branching Guidance

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:

1. проникнуться важностью ветвления и слияния изменений для работы больших команд;
2. узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
3. посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.

Интересен неожиданный термин isolation, обозначающий отделение некоторого потока работ при помощи выбранной техники ветвления. Причем оно отделено от понятия changeset. За подробностями - в статью, по контексту будет понятно, о чём я. В целом же - повторение уже описанных истин о контроле версий :).

Лишний раз утвердился во мнении, что MS знает толк в методологии разработки софта :) потому как не просто дает инструмент для грамотного СМа, но ещё и объясняет - зачем подобные инструменты вообще нужны.

Вот тут - одностраничная HTML-версия.

eTraxis // Теперь в линейке 2.x

Некоторое время назад я участвовал в разработке open source проекта eTraxis — системы отслеживания ошибок, а точнее — системы отслеживания запросов на изменения. Если вдруг кто до сих пор не знает, что это за класс систем — читайте мою статью про системы отслеживания запросов на изменения из цикла материалов по Software Configuration Management.

Система эта предоставляет веб-ориентированный интерфейс — что, в общем-то, уже почти стандарт. Серверная часть традиционна — PHP + Apache, а вот парк СУБД даст фору многим подобным системам: помимо традиционного же MySQL поддерживаются PostgreSQL, MSSQL и Oracle.
Из базовых фич:

SCM // 6. Распределенный контроль версий

Сегодня речь пойдет о довольно спорном и в чём-то провокационном вопросе — распределенных системах контроля версий.

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

Публикация в RSDN Magazine

Вышел в свет RSDN Magazine #2 2009 - именно в нём опубликована первая часть статьи Основы "Software Configuration Management". Первые 2 заметки из цикла "SCM", опубликованные ранее, на 95% состоят из материалов именно этой статьи.

Кстати, на обложке, если приглядеться, можно увидеть мою фамилию и название статьи :)

Статья также опубликована на сайте.

P.S. RSDN Magazine #2'2009, К-Пресс, стр. 15-21, ISSN 0234-6621