Git в картинках на RSDN

Добрейшего.

Постоянные читатели бложика знают мой скепсис по поводу распределённых систем контроля версий вообще и git в частности. Однако нет-нет, да и проскакивают ссылки, которые просто необходимо утащить в нору сохранить в бложике, чтоб не потерялись. Может кому и пригодится.

Сегодня увидел как раз такую - Git в картинках за авторством Игоря Ткачёва, одного из родоначальников и апологетов сообщества RSDN. Название говорит само за себя - объясняется на картинках, как работать с git через git extentions (оконную надстройку над гитом). Объяснение простое и доходчивое, даже я понял что к чему.

В общем, кто давно хотел подружится с git, но боялся ч0рной командной строки и непонятного английского - это для вас.

10 заповедей хорошего контроля версий

Добрейшего.

Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".

Надо бы её перевести, но пока - перечень Важных Вещей:

1. Если используете VSS - бросьте сейчас же. Прям щас!
2. Если что-то не лежит под контролем версий - этого не существует.
3. Делайте коммиты раньше, чаще и не откладывая.
4. Всегда проверяйте изменения перед коммитом.
5. Помните про психопата с топором перед написанием комментариев.
6. Делайте коммиты сами, не перекладывая на других.
7. Версионности БД избежать не получится.
8. Результаты компиляции не кладутся под контроль версий.
9. Никому не интересны ваши личные настройки.
10. Зависимости надо тоже пристроить.

Как-то так. Просто и понятно. Да ещё и написано с юмором, так что рекомендую.

gihub для совместной работы студентов

Добрейшего!

На Хабре опубликовали интересную заметку - Системы управления версиями как инструмент совместной работы студентов. Ещё один интересный пример использования гитхаба не по прямому назначению :) про другой я недавно писал.

Мне, как преподавателю, решение представляется интересным. Повторю здесь то, что написал в комментариях.


Положительные стороны:
- Централизованное хранилище заданий и результатов. Во многих ВУЗах этого до сих пор нет, а тут - всё под рукой. И не будет типичных проблем накануне сессии из серии "у меня вчера вылетел жесткий диск, что смог, то восстановил, поставьте-хотя-бы-тройку!!!" :)
- Обучение системам контроля версий и багтрекингу. Очень правильно.
- Практика командного взаимодействия. Сначала - между преподом и студентом, потом обязательно начинается работа внутри группы. К тому же многие учебные программы имеют курсовые или лабораторные, прямо предназначенные для коллективной работы.

Отрицательные стороны:
- Необходимость наличия интернета. Да, для многих ВУЗов это до сих пор проблема. Кроме того, есть компьютерные классы, где выход в интернет запрещён или невозможен по техническим причинам.
- Привязка с конкретному инструменту. git и те тулзы, которые доступны на гитхабе - на них свет клином не сошелся. Есть, к примеру, ещё и централизованные VCS, они всё ещё имеют немалое право на существование, особенно коммерческие решения. В общем, получится очень однобоко, а это не есть правильно с точки зрения учебного процесса.
- Работа на стороннем сервисе. Пользователь не контролирует данные, находящиеся на сервисе. Но поскольку данные эти - не несут коммерческой инфы и их утрата не окажет большого влияния на учебу в целом (есть локальные копии), то минус это небольшой.
- Нет гарантии, что гитхаб не изменит свою политику и не ограничит подобные варианты использования.

А вообще - интересно.

Узелок на память: upgrade Mercurial 1.8 для Ubuntu 10.04

Добрейшего.

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

Вводная. В общем, не так давно я таки поставил себе Убунту и начал с энтузазизьмом её заселять и осваивать на предмет замены Виндоуз в кажестве десктопа. И поскольку с некоторых пор активно использую для личных нужд Mercurial (параллельно с Subversion, да) - поставил и его туда.

Проблема. С Убунтой 10.04 (на мой новый ноут встала только она, 10.10 залазить не хотела) идет Ртутный версии то ли 1.5, то ли 1.6. Я же использовал к тому времени 1.8 и, как выяснилось, старые версии с репами от более новых версий работать отказываются. Убунтовый тул для апгрейда показывал, что в Убунтовых репозиториях доступна только старая версия.

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

> sudo add-apt-repository ppa:mercurial-ppa/releases
> sudo apt-get update
> sudo apt-get install mercurial

Проверяем результат с помощью

> hg --version


Кому надо ещё проапгрейдить TortoiseHg - в статье и про это есть.

Пример описания процесса создания релизов

Добрейшего!

Не так давно (ну хорошо, почти год назад) я решил сформулировать для себя задачи по улучшению инфраструктуры разработки. Проще говоря - надо было уже начать что-то менять в SCM-процессе, и не только в нём.

Упоминавшаяся там команда Ф - достаточно обособленная, но самая крупная, и задачи решает самые разнообразные. Так вот, один из разработчиков нашел время и описал процесс построения билдов и всего, что с этим связано. Фактически, описан процесс выпуска релизов от  получения исходников до начала развёртывания. Применяется много практик из continuous integration, но ими не ограничивается, а сам процесс описывается для Java.

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

eTraxis теперь доступен в облаке

Добрейшего

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

Собственно, хотелось поделиться радостной новостью - eTraxis теперь доступен не только в виде исходников для самостоятельного развертывания у себя в команде. Теперь это ещё и сервис, работающий по модели SaaS - https://www.etraxis.com/.

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

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

Да, кстати, регистрация и использование - бесплатны. Что, конечно же, не мешает ткнуть благодарным пользователям на кнопочку Donate и перечислить малую толику :)

В общем - не сидим, регаемся и начинаем работу. :)

SCM - в массы, или Книжка, которую пишут в github

Добрейшего.

На Хабре сегодня зацепил взгляд заголовок, содержащий слова "литературное произведение, создаваемое с помощью GitHub". В мозгу сработало ключевое слово - и вот я уже читаю о том, как на github энтузиаст начал писать книжку научно-фантастического уклона.

По итогу порадовал сам факт, что контроль версий начал выходить за рамки традиционного применения. Фраза "разветвление сюжета" заиграла новыми красками :)

Конечно, инициатору ещё предстоит столкнуться с массой проблем, порождённых таким демократическим подходом. Чего будут стоить "форки" сюжета, заe которыми будет трудно уследить даже дотошному читателю. Однако - может получиться занятно.

Начинаю ждать кино, выложенное в Mercurial на Google Code через YouTube ;)

P.S. И почему мне упорно вспоминается "t" Пелевина? :)

Управление изменениями и кессонная болезнь проектов

Добрейшего!

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

Итак, для сайта OpenQuality.ru написал программную статью Управление изменениями и кессонная болезнь проектов. Получилось много и подробно - спасибо редактору сайта Юрию за правильно поставленные вопросы и предложения. Статья, как можно понять из названия - про то, как управлять изменениями в проекте и как изменяющийся масштаб проекта влечет за собой то, что у людей принято называть декомпрессионной болезнью (кессонкой).

В общем, читаем и высказываемся в комментариях к статье.

Используем git для управления сайтом

Добрейшего.

Я достаточно давно работаю в отрасли разработки приложений для веба, поэтому всегда с двойным интересом читаю материалы о применении SCM для веб-разработки. Поэтому этот материал особенно порадовал: Using Git to manage a web site, что означает примерно "Как с помощью гита управлять веб-сайтом".

Идея, в общем-то, не нова. Берём git, создаем репо у себя и репо на сервере, где лежит сайт. Далее с помощью напильника и механизма хуков (hooks) настраиваем, чтобы при получении очередной дельты через push, локальная копия исходников сайта обновлялась из репозитория. Разработчик меняет код, делает push на сервер, там срабатывает хук, который разворачивает новые исходники в ту директорию, где у вашего сайта DocumentRoot.

Думаю, что-то аналогичное можно придумать и для Mercurial.

Для тех, кто использует распределённые системы контроля и пишет под веб, это хорошее решение.

Как выбирали между Mercurial и git для Google Code

Добрейшего.

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

С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.

Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.

P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.

Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem