Рассуждения о стоимости заказной разработки программного обеспечения

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

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

Деньгами не обижу, даю 20 тысяч!

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

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

Когда речь зашла о бюджете, нам сказали что проект срочный, что сделать надо за 2 недели (как раз с этого дня), и поэтому с деньгами нас не обидят. Правда из документации, требующейся программисту, у них на всю систему была только тонюсенькая методичка по протоколу взаимодейтсвия, и ничего больше у них не было. Заказчик упорно пытался увильнуть от ответа, сколько же он денег предполагает потратить, но все таки раскололся, и огласил гигантскую сумму в 20 тысяч рублей! Я чуть не рассмеялся прямо там же, но совладал с собой

Когда прошла первая волна эмоций, мы попробовали объяснить, что такие проекты нереально сделать за 20 тысяч, и также нереально сделать за 2 недели. Заказчик говорил, что вот, посмотрите, мы вам программы показывали! Они вообще бесплатные! Правда он забыл упомянуть что они идут в комплекте к серийной системе сбора информации, которая сама стоит приличных денег. В целом закончилось все хорошо - посмеялись и разошлись :)

Система лицензирования и оплаты за 6000!

Буквально сегодня зашел на weblancer.net и увидел, что некто хочет получить систему лицензирования и оплаты по СМС и пластиковым картам за 6000 рублей и в срок 1 неделя. Мне очень интересно было бы поговорить с заказчиком, что именно он хочет получить? Готов ли он доверить свои деньги и свой софт (который он по всей видимости собрался защищать) разработке неизвестного студента который будет это делать за пожрат. Может проще не защищать? Ведь это по всей видимости дешевле будет! А если уж защищать, то почему не заплатить $400-$600 за более-менее нормальную систему, которая конечно ничего не гаратирует, но от ручонок школьников вполне может помочь.

То же самое с оплатой по смс и картам, ведь это же деньги. Как можно доверять системе за 6000 которая будет это делать? Человек уверен что он сможет верифицировать код на наличие дырок, которые переводят деньги тому самому фрилансеру? Кто потом будет поддерживать код, если потребуется его куда-то перенести? Как вообще это можно сделать за одну неделю? Да, оплата через пластик это несложно, достаточно заключить договор с агрегатором и написать небольшой кусок для обертки его API, и да, какую-то версию можно сделать за неделю. Но стоит ли неделя разработки 6000? А офис? А интернет? А налоги?

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

Откуда берется стоимость часа работы

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

Итак начнем. Из чего же складывается стоимость разработки:

1. Зарплата. Примем зарплату разработчика равную 25000 рублей в месяц. На руки.
2. Начисления на зарплату и налоги. Если это организация на упрощенной схеме налогообложения, то это примерно 50% от чистой зарплаты (подоходный, пенсионные, ФСС)
3. Отпускные. Нужно же отдыхать? Пусть будет 10% от зарплатных затрат.
4. Непроизводительные расходы. Сюда входит ожидание ответов от заказчиков, выяснение требований, время на сдачу проекта, разборки с глюками сторонних библиотек и интерфейсов. Это примерно 10% от затрат. И это очень низкая оценка.
5. Офис, интернет, мебель, железо и софт. По реальным оценкам - это где то 5000 в месяц. Опять же, очень низкая оценка, но жить, в принципе, можно.
6. Риски. Всегда есть шанс недооценить проект, просчитаться по срокам, или вляпаться в неадекватного заказчика, у которого "хотелки" будут составлять столько же, сколько основной проект. Ну пусть тоже 10%.
7. Прибыль. Нужно же еще и развиваться, что то делать для себя, покупать компоненты и т.д. ну пусть будет 10%. Так сказать по европейски скромно (сейчас это процент по рублевому банковскому депозиту).

Давайте просто арифметически прикинем во что это выливается. Я прикинул в экселе, и получается что необходимо иметь входящих 55500 рублей в месяц. Чтобы все получилось так, как я описывал выше. То есть от чистой зарплаты это больше чем в 2 раза! И это я взял еще маленькую зарплату, за которую в провинции можно найти человека, с более-менее адекватной квалификацией. Но в городах с развитым IT сектором на такую зарплату к вам пойдут только умственные инвалиды. Если посчитать стоимость часа (в среднем в месяц рабочих часов 164) то получается примерно 340 рублей. То есть уже больше $10. И это я оценил по минимальной планке!

Именно поэтому во всем цивилизованном мире уже известно, что лучше заплатить за готовый, серийный продукт чем написать свой такой же. Разница в стоимости будет минимум в десятки раз! Думаю теперь становится понятно, почему нельзя сделать систему защиты за $200, и систему контроля нефтехранилища за $700. Стоит ли говорить сколько подобных неадекватных заказчиков мы уже повстречали? Я уже не знаю как объяснить людям, что работа, котороая требует привлечения высококвалифицированных сотрудников не может стоить столько же сколько работа уборщицы или грузчика. Что странно доверять людям, которые просят за свою работу существенно меньше чем она того стоит. Что нужно учиться считать деньги, и считать их. Когда у вас болит зуб, и вам его выдергивают, и берут 700-1000 рублей фактически за 30 минут, вас это не смущает!

Джоел и Subversion, Mercurial, Git. Действительно антибиотик?

Недавно в блоге Джоела Спольски была опубликована последняя статья – «Distributed Version Control is here to stay, baby», по крайнее мере сам Джоель называет её последней. Статья, как понятно из заглавия посвящена распределенным системам контроля версий. После прочтения статьи возникло желание немного её прокомментировать. Сначала я выложу краткий обзор содержания, при этом постараюсь не упустить важных моментов. Делать полноценный перевод нет ни времени, ни желании. Итак, Джоел пишет следующее…

В распределенных системах контроля версий их распределенность не является самой интересной особенностью. Наиболее интересным является изменение модели – распределенные системы контроля версий работают с изменениями (changes), а не с версиями. Если централизованная система контроля версий «думает»: у меня есть версия 1, после этого будет версия 2, после этого версия 3 и так далее. В распределенной системе все по другому: сначала не было ничего, потом добавлены эти изменения, потом добавлены те, и т.д. Изменение программной модели должно изменить модель пользователя. Теперь пользователю тоже придется мыслить в терминах изменений. Если раньше было: «Я хочу получить версию номер Х», или «Я хочу последнюю версию», то теперь: «Хочу получить набор изменений Пети».

Это смена парадигмы! Именно поэтому, когда вы переходите с Subversion на Mercurial, у вас вроде бы все получается, но вас новая система все время расстраивает, вы не можете к ней привыкнуть, и начинаете её ненавидеть. Только когда вы начнете мыслить в терминах «изменении», и выбросите из головы «версии» все встанет на свои места. Именно изменение модели работы системы контроля версий привело к существенному упрощению слияния (merge) кода. И соответственно к более активному использованию ветвления, использованию его там, где оно необходимо. Теперь можно не думая о сложностях последующего слияния создавать долгоживущие ветви для команд тестирования и поддержки и создавать короткоживущие ветви для экспериментов.

Если вы все еще используете SVN – перестаньте. Mercurial и Git – это антибиотики. Теперь существуют технология лучше.

И, вы знаете, я с Джоелом согласен почти полностью. Джоел смог объяснить то, что понимает каждый, кто освоился в распределенных системах. Но не каждый сможет выразить это словами. Это действительно смена основной концепции системы контроля версий, и именно из-за этого DVCS так туго входят в коллективы программистов. Наблюдаю это на личном опыте. Все привыкли мыслить категориями Subversion, и как только человек видит новую ветку в репозитории, даже ту, которая по идее скоро сольется с основной – он почему то пугается.

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

Однако распределенные системы контроля версий – это отнюдь не антибиотики. Главная проблема, как и всегда, в головах. И без решения этой проблемы никакой Hg, Git или Bazaar не спасет. Да, они гораздо больше соответствуют workflow разработки ПО, и большинство действий в этих системах легко объясняется логической необходимостью и разумностью. Но способов выстрелить себе в ногу в них значительно больше, хотя они и не очевидны. Наблюдал однажды картину, когда 4 разработчика постоянно работали каждый в своей ветке – в этом случае никакая смена парадигмы контроля версий не поможет.

Распределенные системы контроля версий – это отличная вещь, это действительно шаг вперед, который открывает каждому разработчику новые возможности и новую функциональность. И это действительно происходит за счет смены модели взаимодействия, Джоэл, безусловно, прав. Но, мне кажется, воспринимать их как серебряную пулю неправильно. Они избавляют от значительной части головной боли связанной с контролем версий, ветвлениями и слиянием. Однако от кривых рук они все равно не вылечат. Поэтому все равно необходимо нормально разбивать задачи, думать головой, и мержиться не раз в месяц с десятком изменений в каждом файле от каждого автора. Тут уж никакой Mercurial не спасет.

Известные баги System.Net.Mail.SmtpClient в .NET 3.5

Сегодня открыл для себя некоторые глюки класса System.Net.Mail.SmtpClient в .net framework 3.5. (Я уже не говорю что творилось с System.Web.Mail.*, но оно уже obsolete и слава небесам. RIP).

1. Некорректная реализация команды EHLO протокола SMTP. Согласно RFC#821 ещё лохматого года необходимо передавать FQDN хоста-отправителя, причем по RFC это правило строгое. Вместо этого в MS решили, что хватит и NetBIOS-имени компа. Соответственно сервера, не отклоняющиеся от стандарта посылают ентот SmtpClient лесом, как пытающийся разослать спам. Решения нет. Есть только очень неочевидный WorkAround через Reflection.

2. Вытекает из первого. MS хотела как лучше, и разрешила называть компьютеры в NetBIOS сетях именами с символами из национальных алфавитов. Мало того, собсно Windows 7 RU предлагает подобное имя при установке! (Правда при попытке сменить руками, уже после установки, честно предупреждает что нехорошо использовать символы русского алфавита). И, как я уже говорил выше, это NetBIOS-имя использует SmtpClient в качестве имени хоста, правда никак не кодируя символы национальных алфавитов. После чего сам же валится с исключением "недопустимый знак в заголовке электронной почты". Собственно исключение то другое, но вот InnerException именно такой. Решения нет. Есть только очень неочевидный WorkAround через Reflection.

3. Очень интересный взгляд на стандарты почтовых протоколов со стороны MS. Все уже привыкли, что MS если и читает чужие стандарты, то как то очень избирательно. Вот и стандарт на SMTP также ими был прочитан. И, соответственно, также реализован. Что привело к тому, что некоторые SMTP сервера напрочь не работают с SmtpClient от MS. Например Kerio. Решения нет. WorkAround'ов нет.

Обиднее всего то, что все это хозяйство тянется ещё с .net 2.0, все эти баги давно зарегистрированы, но MS плевало на отправку почты. Надо бы их SmtpClient с hotmail'ом проверить. Интересно, заработает ли?

Введение в Mercurial. Часть 4. Способы организации ветвей

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

Для начала дадим определения ветви, чтобы начинать с единого понимания процесса. Обратившись к wiki меркуриала я нашел определение, которое мне кажется вполне корректным: ветвь (branch) - это связанная последовательность ревизий (changeset) являющаяся отдельным направлением разработки. Таким образом, ветвь - это в первую очередь логическое понятие, так как в случае с распределенными системами контроля версий она будет содержать значительное число "спонтанных" ветвлений-слияний.

Рисунок 1. Исходное состояние репозитория

Рисунок 2. Новая анонимная ветвь в репозитории

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

$ hg branches
default                        4:6d6c634e2e20

Команда hg branches выводит список всех именованных ветвей в репозитории. Как мы видим основная ветвь разработки называется default. Если быть точным, так называется ветвь в которую происходит первый коммит в репозиторий, так сказать название по умолчанию. На рисунке 1 приведено текущее состояние репозитория и граф ревизий в нем находящихся. Я буду красным кружком отмечать "вершину" (tip) репозитория, как сказано в документации Mecurial, вершина - это самая свежая ревизия в репозитории. Команда hg branches не выводит анонимные ветви, хотя разработчики могут их использовать при необходимости, и создавать самостоятельно.

Анонимное ветвление

На самом деле, создание ветви при работе с Mercurial не является чем-то из ряда вон выходящим, для распределенной модели контроля версий это стандартная операция, и поэтому может быть произведена крайне просто, фактически, простым коммитом. То есть мы должны привести рабочую копию в состояние отличное от "вершины" (tip), внести изменения и выполнить коммит. Ничего больше. Для этого локальную копию исходного кода вернем в состояние ревизии 2:66c5686e355e:

$ hg update -r 66c5
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ ls -l                   
-rw-r--r-- 1 mike mike 22 2010-01-07 22:22 first.txt         
-rw-r--r-- 1 mike mike 61 2009-11-27 11:15 other.txt         
-rw-r--r-- 1 mike mike 57 2009-11-27 00:03 readme.txt    

После этого создадим в локальной копии файл branch.txt, добавим его в репозиторий и выполним коммит:

$ ls -l
-rw-r--r-- 1 mike mike 61 2010-01-31 18:55 branch.txt
-rw-r--r-- 1 mike mike 22 2010-01-07 22:22 first.txt 
-rw-r--r-- 1 mike mike 61 2009-11-27 11:15 other.txt
-rw-r--r-- 1 mike mike 57 2009-11-27 00:03 readme.txt
$ hg add
adding branch.txt
$ hg commit
created new head
$ hg branches
default                        5:ff8ffd5270cb

И Mercurial нам честно сообщает что создал новую "голову". На рисунке 2 показано текущее состояние репозитория. Отмечу два момента: во-первых, ветвь default осталась на своем месте, и теперь заканчивается ревизией 5:ff8ffd5270cb, то есть "вершиной" (tip); а во-вторых все эти ветвления находятся локально в нашем репозитории. Локальность производимых ветвлений - это главное, коренное, отличие от централизованных систем контроля версий, в том числе от Subversion. Никто не увидит вашей ветви до тех пор пока вы не синхронизируете свой репозиторий с удаленным (обычно командой push). С другой стороны выполнение pull приведет к появлению в вашем репозитории всех ветвей, имеющихся в удаленном.

Преимущества

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

Недостатки

Недостатки вытекают из анонимности ветви. Фактически, понять, что у вас есть ветвь разработки, исходя из вывода стандартных операций Mercurial, затруднительно. Особенно после 2-3 месяцев активной работы с репозиторием, когда количество таких мелких ветвлений приближается к сотне. Соответственно вам придется писать информативные подписи к коммитам, если анонимные ветви предполагается использовать в дальнейшем. Для переключения между ветвями разработки вам придется использовать номер ревизии, который, как известно, простой хэш - очень удобен для машины, но крайне неудобен для человека.

Таким образом, анонимные ветви - это отличный механизм для внесения быстрых (по количеству ревизий) исправлений, логически сильно связанных с направлением основной ветви разработки, то есть для организации ветвления на 2-3 ревизии с последующим слиянием с основной ветвью. Для организации больших ветвей, логически необходимых для разделения направлений разработки следует использовать именованные ветви.

Именованное ветвление

Рисунок 3. Именованные ветви в репозитории

Вполне естественно, что в Mercurial предусмотрен способ создания ветвей разработки с некоторыми именами, задаваемыми пользователем. Для организации подобных ветвлений предназначена команда hg branch. С помощью этой команды версия, находящаяся в локальной копии помечается ветвью с новым именем, при этом сама ветвь будет создана только после того, как вы выполните коммит. Попробуем сейчас сделать именованную ветвь, родительской ревизией для которой будет ff8f:

$ hg branch new_feature
marked working directory as branch new_feature
$ hg commit
$ hg branches
new_feature                    6:4d530267d302
default                        5:ff8ffd5270cb

Итак мы видим, что Mercurial уже знает про две именованные ветви, "вершинами" для которых являются ревизии ff8f и 4d53, хотя на графе ревизий это одна ветвь. На рисунке 3 я показал, что именно понимается под именованной ветвью в Mercurial, при этом, фактически, для каждой ветви есть своя "вершина" (tip), хотя hg log это не показывает (я приведу только смысловой отрывок):

$ hg log
changeset:   6:4d530267d302
branch:      new_feature
tag:         tip
user:        mike@mike-vbox
date:        Sun Jan 31 21:31:07 2010 +0300
summary:     Создаие именованной ветви в репозитории

changeset:   5:ff8ffd5270cb
parent:      2:66c5686e355e
user:        mike@mike-vbox
date:        Sun Jan 31 18:56:23 2010 +0300
summary:     Создание анонимной ветви

changeset:   4:6d6c634e2e20
parent:      3:6872fa960507
parent:      2:66c5686e355e
user:        mike@mike-vbox
date:        Sun Jan 10 20:34:21 2010 +0300
summary:     Выполнен мерж двух веток

changeset:   3:6872fa960507
parent:      1:270e49e72f4b
user:        mike@mike-vbox
date:        Sun Jan 10 19:40:45 2010 +0300
summary:     Файл second.txt создан во втором репозитории

Убедиться в том, что "вершины" все таки существуют можно с помощью hg update, то есть переключившись на другую ветвь:

$ hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg ident
ff8ffd5270cb

А затем переключится обратно:

$ hg update new_feature
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg ident
4d530267d302 (new_feature) tip

При этом в нашем репозитории сложилась интересная ситуация. tip ветви default не совпадает с "головой" (head) этой же ветви. В этом легко убедиться попросив Mercurial сказать какие же "головы" в нашем репозитории:

$ hg heads
changeset:   6:4d530267d302
branch:      new_feature
tag:         tip
user:        mike@mike-vbox
date:        Sun Jan 31 21:31:07 2010 +0300
summary:     Создаие именованной ветви в репозитории

changeset:   4:6d6c634e2e20
parent:      3:6872fa960507
parent:      2:66c5686e355e
user:        mike@mike-vbox
date:        Sun Jan 10 20:34:21 2010 +0300
summary:     Выполнен мерж двух веток

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

Преимущества

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

Недостатки

К недостаткам, в некоторой степени, можно отнести синдром разрастания ветвей. То есть, если вы будете использовать именованные ветви при каждой необходимости отпочковаться от основной, вывод команды hg branches будет просто гиганским через некоторое время. Хотя ветви можно закрывать при коммитах (опция --close-branch), не стоит делать именованные ветви там где они не нужны.

Ветвление в клонах репозитория

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

Преимущества

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

Недостатки

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

На этом я заканчиваю рассматривать ветвления в Mercurial. Думаю следующая статья будет посвящена способам слияния ветвей, а также сложным моментам при слиянии, при упоминании которых у пользователей Subversion резко падает давление и начинают трястись руки. :)

Уважаемые читатели. Просьба комментировать посты. Возможно я упустил какие-то моменты, требующие разъяснения, о которых стоило бы написать.

Введение в Mercurial. Часть 3. Начинаем ветвиться и сливаться

Продолжаю писать про систему контроля версий Mercurial. В этой части начну речь про сложные операции с репозиториями, а именно - создание ветвей и работа с ними. Работа с ветвями разработки пользователям Subversion доставляет немало головной боли, поэтому многие из них, когда видят во всех статьях про Mercurial, что им чуть ли не каждый день придется мержить (merge) ветки сильно пугаются, и теряют всякое желаение переходить на него. Однако я постараюсь переубедить всех недоброжелателей и консерваторов, поскольку в Mercurial работа с ветвлениями является не намного более сложной операцией чем коммит.

Перед тем как продолжить разбираться с Mercurial поздравляю всех своих читателей с наступившим новым годом, желаю всяческих успехов в различных аспектах жизни, гармонии и добра во внутреннем мире, а также постоянного интеллектуального и духовного роста! С новым годом, уважаемые!

Итак, мы уже разбирали основы работы с репозиториями Mercurial в предыдущей части, и у нас сформировалось 2 готовых репозитория, сегодня мы продолжим взаимодействовать с ними и разберем, как организовать ветвление, и как потом с ним "бороться". В этой части мы рассмотрим самое частое ветвление в Mercurual, которое можно даже назвать "спонтанным".

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

Для начала создадим файл first.txt в первом репозитории, закоммитим его и запушим:

$ echo "new text to first.txt" > first.txt
$ hg status
? first.txt      
$ hg add first.txt
$ hg commit
$ hg outgoing
comparing with /home/mike/Repositories/newProject
searching for changes
changeset:   2:66c5686e355e
tag:         tip
user:        mike@mike-vbox
date:        Thu Jan 07 22:28:39 2010 +0300
summary:     Коммит файла first.txt в первом репозитории
$ hg push
pushing to /home/mike/Repositories/newProject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

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

$ echo "file created in second repository" > second.txt
$ hg status
? second.txt
$ hg add
adding second.txt
$ hg commit
$ hg log
changeset:   2:6872fa960507
tag:         tip
user:        mike@mike-vbox
date:        Sun Jan 10 19:40:45 2010 +0300
summary:     Файл second.txt создан во втором репозитории

changeset:   1:270e49e72f4b
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории

changeset:   0:8fae369766e9
user:        mike@mike-notebook
date:        Fri Nov 27 08:58:01 2009 +0300
summary:     Файл readme.txt добавлен в репозиторий

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

$ hg outgoing
comparing with /home/mike/Repositories/newProject
searching for changes
changeset:   2:6872fa960507
tag:         tip
user:        mike@mike-vbox
date:        Sun Jan 10 19:40:45 2010 +0300
summary:     Файл second.txt создан во втором репозитории

$ hg push
pushing to /home/mike/Repositories/newProject
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

Итак Mercurial нам запрещает пушить, говорит что пуш приведет к созданию новой головы в удаленном репозитории. И предлагает смержить репозитории. Ну чтож давайте это сделаем:

$ hg incoming
comparing with /home/mike/Repositories/newProject
searching for changes
changeset:   2:66c5686e355e
tag:         tip
user:        mike@mike-vbox
date:        Thu Jan 07 22:28:39 2010 +0300
summary:     Коммит файла first.txt в первом репозитории

$ hg pull
pulling from /home/mike/Repositories/newProject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

Мы вытянули с "центрального" репозитория все имеющиеся изменения, и Mercuial нам сообщает, что в локальном репозитории теперь две "головы" которые требуют слияния (мержа от английского to merge). Можно даже попросить Mercurial показать некоторую картинку (используется дополнение graphlog о котором я ещё не писал, расширение есть в стандартной поставке):

$ hg glog
o  changeset:   3:66c5686e355e
|  tag:         tip
|  parent:      1:270e49e72f4b
|  user:        mike@mike-vbox
|  date:        Thu Jan 07 22:28:39 2010 +0300
|  summary:     Коммит файла first.txt в первом репозитории
|
| @  changeset:   2:6872fa960507
|/   user:        mike@mike-vbox
|    date:        Sun Jan 10 19:40:45 2010 +0300
|    summary:     Файл second.txt создан во втором репозитории
|
o  changeset:   1:270e49e72f4b
|  user:        mike@mike-notebook
|  date:        Fri Nov 27 10:39:35 2009 +0300
|  summary:     Записан файл other.txt в другом репозитории
|
o  changeset:   0:8fae369766e9
   user:        mike@mike-notebook
   date:        Fri Nov 27 08:58:01 2009 +0300
   summary:     Файл readme.txt добавлен в репозиторий

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

$ hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ ls
first.txt  other.txt  readme.txt  second.txt

Итак, Mercurial, после нашей команды "hg merge" смержил рабочую копию и репозиторий, и напоминает нам, что эти изменения следовало бы закоммитить. Так сделаем это:

$ hg commit
$ hg glog
@    changeset:   4:6d6c634e2e20
|\   tag:         tip
| |  parent:      2:6872fa960507
| |  parent:      3:66c5686e355e
| |  user:        mike@mike-vbox
| |  date:        Sun Jan 10 20:34:21 2010 +0300
| |  summary:     Выполнен мерж двух веток
| |
| o  changeset:   3:66c5686e355e
| |  parent:      1:270e49e72f4b
| |  user:        mike@mike-vbox
| |  date:        Thu Jan 07 22:28:39 2010 +0300
| |  summary:     Коммит файла first.txt в первом репозитории
| |
o |  changeset:   2:6872fa960507
|/   user:        mike@mike-vbox
|    date:        Sun Jan 10 19:40:45 2010 +0300
|    summary:     Файл second.txt создан во втором репозитории
|
o  changeset:   1:270e49e72f4b
|  user:        mike@mike-notebook
|  date:        Fri Nov 27 10:39:35 2009 +0300
|  summary:     Записан файл other.txt в другом репозитории
|
o  changeset:   0:8fae369766e9
   user:        mike@mike-notebook
   date:        Fri Nov 27 08:58:01 2009 +0300
   summary:     Файл readme.txt добавлен в репозиторий

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

$ hg push
pushing to /home/mike/Repositories/newProject
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files

Теперь переместимся в каталог первого разработчика, и получим изменения и из центрального репозитория:

$ hg pull
pulling from /home/mike/Repositories/newProject
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 2 files
(run 'hg update' to get a working copy)
$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg glog
@    changeset:   4:6d6c634e2e20
|\   tag:         tip
| |  parent:      3:6872fa960507
| |  parent:      2:66c5686e355e
| |  user:        mike@mike-vbox
| |  date:        Sun Jan 10 20:34:21 2010 +0300
| |  summary:     Выполнен мерж двух веток
| |
| o  changeset:   3:6872fa960507
| |  parent:      1:270e49e72f4b
| |  user:        mike@mike-vbox
| |  date:        Sun Jan 10 19:40:45 2010 +0300
| |  summary:     Файл second.txt создан во втором репозитории
| |
o |  changeset:   2:66c5686e355e
|/   user:        mike@mike-vbox
|    date:        Thu Jan 07 22:28:39 2010 +0300
|    summary:     Коммит файла first.txt в первом репозитории
|
o  changeset:   1:270e49e72f4b
|  user:        mike@mike-notebook
|  date:        Fri Nov 27 10:39:35 2009 +0300
|  summary:     Записан файл other.txt в другом репозитории
|
o  changeset:   0:8fae369766e9
   user:        mike@mike-notebook
   date:        Fri Nov 27 08:58:01 2009 +0300
   summary:     Файл readme.txt добавлен в репозиторий

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

А теперь думаю самое главное - зачем же все это надо, ведь в SVN нет подобных проблем, да и мержить там не так часто... Ответ здесь очень простой - подобная модель взаимодействия с репозиторием провоцирует пользователя на частые коммиты, он не боится сломать код или репозиторий неудачным коммитом, не боится помешать другим пользователям и т.д. Коммит в Mercurial локален - пока вы не захотите отправить его в другой репозиторий, вся ветка коммитов останется у вас. К тому же слияние ревизий в Mercurial сделано намного проще и логичнее слияния ревизий в Subversion. Да, в поздних версиях и SVN научился более-менее нормально мержить, однако до Mercurial ему по прежнему далековато. И именно возможность частых локальных коммитов, в том числе когда у вас отстутствует подключение к интернету (а со мной такое случается нередко), меня так привлекла в Mercurial. Все остальные аспекты были на втором плане.

В заключении сделаю одно важное замечание. В случае командной разработки, у Mercurial есть одна особенность (назвать недостатком как-то язык не поворачивается): целочисленная нумерация ревизий может быть различна в различных репозиториях, поэтому не стоит использовать целочисленные номера для идентификации ревизий при общении внутри команды. Поскольку идентифиратором ревизии в Mercurial является SHA1-хеш, вероятность совпадения которого для различных ревизий крайне мала, то стоит использовать именно его. Причем как показывает практика различных пользователей Mercurial - вполне достаточно первых 4х символов этого самого хеша (когда вам перестанет хватать 4х символов - используйте 5 ;) ).

Введение в Mercurial. Часть внеочередная. Конвертируемся из Subversion

Всем привет!
Давненько я ничего не писал, но для того была достойная причина - 22 декабря я все таки защитил кандидатскую, что собственно и забирало уйму времени последние месяцы. Теперь я полноправный к.т.н.

Сегодня маленький пост о том как сконвертировать имеющийся репозиторий Subversion в репозиторий Mercurial. Думаю что в необходимости перехода на Mercurial я постепенно смогу убедить своих читателей. Итак исходная позиция:
1. Имеется репозиторий svn лежащий на диске, пусть здесь: /[svn_repos_path]/svnrepo;
2. Хочется заиметь репозиторий Mercurial /[hg_repos_path/hgrepo со всей историей накопленной в Subversion, фактически импортировать все ревизии из svn в Mercurial.
Нет ничего проще.
1. Создаем новый репозиторий Mercurial:

mkdir /[hg_repos_path/hgrepo
cd /[hg_repos_path/hgrepo
hg  init

2. Разрешаем расширение convert. В Debian это делается так: в файл /[hg_repos_path/hgrepo/.hg/hgrc добавляем строчки:

[extensions]
convert=

3. А теперь выполняем собственно конвертирование:

cd /[hg_repos_path/hgrepo
hg convert file:///[svn_repos_path]/svnrepo .

Все. Mercurial выдает последовательность ревизий, и загоняет все что было в SVN репозитории в новый репозиторий Mercurial. Можно пользоваться ;)

Введение в Mercurial. Часть 2. Основы работы

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

Основные сведения о ревизиях в Mercurial

Как и в большистве существующих систем контроля версий, центральным понятием Mercurial являетя ревизия, которая здесь называется changeset. В связи со спецификой распределенных систем контроля версий невозможно выдать каждой ревизии её номер, поскольку не получится гарантировать его уникальность среди всех существующих репозиториев. Однако  каждая ревизия все таки имеет уникальный идентификатор, в случае Mercurial это 40-значный sha1-хеш, который учитывает все параметры ревизии. Таким образом, у каждой новой ревизии в любом удаленном репозитории будет свой уникальный идентификатор. Использование подобной нумерации ревизий немного пугает начинающих пользователей, особенно переходящих на Mercurial с svn, однако ничего страшного в них нет, и использование тех или иных идентификаторов это просто дело привычки.

Начало работы

Вся работа с системой котроля версий Mercurial происходит с помощью команды hg, и во всех постах посвященных работе непосредственно с Mercurial, я буду приводить именно консольные команды, и консольные способы работы. Безусловно есть и вполне нормальные GUI-клиенты, однако освоение лучше начинать именно с консоли, чтобы лучше понять как именно все работает, и каковы логические и алгоритмические основы взаимодействия с этой системой контроля версий.

Работа с этой системой контроля версий, как, впрочем, и со всеми остальными, начинается с создания репозитория в пустом каталоге файловой системы. Для этого перейдём в выбранный каталог, пусть это будет ~/repos/hgproject, и скажем:

> hg init

По команде «hg init» Mercurial создает репозиторий в текущем каталоге. Если посмотреть на результат работы — мы увидим  каталог «.hg», в которой собственно и хранится вся история работы над проектом.

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

Теперь нужно получить данные для начала работы над проектом. В общем случае это будет все содержимое некоторого репозитория расположенного где-то на сервере. Для этого перейдем в ~/projects и скомандуем:

> hg clone ~/repos/hgproject

По команде «hg clone» Mercurial «клонирует» репозиторий расположенный по указанному адресу в текущий каталог. При этом к вам попадает именно репозиторий, то есть хранилище, содержащее всю существующую историю изменений, что сильно отличает операцию клонирования от того же checkout в Subversion. Таким образом, у нас уже имеется два репозитория — то есть мы локально получили именно распределенную систему контроля версий. Взаимодействие может происходить с любым имеющимся репозиторием, так как они все равноценны, однако мы назовем репозиторий в каталоге ~/repos/hgproject "центральным", то есть введем конвенцию на взаимодействие с системой. Практически в любом случае работы в команде без подобных конвенций не обойтись.

Работа с локальным репозиторием

Начнем взаимодейтсвовать с полученной структурой репозиториев. С помощью вашего любимого текстового редактора создадим новый файл в каталоге с проектом, пусть для примера это будет readme.txt, и напишем некую строку символов в этот файл. Итак мы уже получили файлы в проекте, которые необходимо хранить в репозитории. Перед тем, как сохранить новый файл в репозитории сначала убедимся в том, что Mercurial его видит, для этого в каталоге с новым файлом выполним:

>hg status
? readme.txt
Mercurial ответил, что он видит файл readme.txt, при этом этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). По команде status Mercurial выводит состояние рабочей копии в сравнении с состоянием локального репозитория. Для того, чтобы сказать Mercurial, что его необходимо версионировать скажем:

> hg add
adding readme.txt

И ещё раз:

> hg status
A readme.txt

Видим, что слева от имени файла появился символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите, который мы сейчас и сделаем:

>hg commit

Mercurial запустит текстовый редактор и попросит ввести описание к выполняемому коммиту. Как только вы закроете его все изменения в рабочей копии будут сохранены в локальном репозитории. Убедиться в этом достаточно просто:

>hg log
changeset:   0:8fae369766e9
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 08:58:01 2009 +0300
summary:     Файл readme.txt добавлен в репозиторий

Разберем, что Mercurial выдал в этом сообщении. Changeset — это и есть номер ревизии, который состоит из двух частей: виртуального номера ревизии(записан до «:») и идентификатора (sha1-хеша). Виртуальный номер ревизии призван облегчить жизнь пользователям, и все-таки ввести в эту систему некоторую нумерацию ревизий. Но, как показывает практика использовать этот номер для однозначной идентификации нельзя, так как может привести к путанице в понимании происходящего в репозиториях. Обычно для однозначной идентификации версии достаточно 4-5 шестнадцатеричных цифр идентификатора. Следующей строкой идёт «tag: tip», вообще говоря tip — это обозначение последней ревизии, хотя выбирается это обозначение в различных случаях по различным принципам, в дальнейшем, когда будем рассматривать организацию ветвлений этот момент исследуем более подробно. Значение следующих строк очевидно, и нет необходимости их как-либо комментировать.

Обмен с удаленными репозиториями

А теперь вспомним, что у нас есть ещё некий «центральный» репозиторий, через который, по идее будет происходить взаимодействие с другими членами команды разработки. При этом выполненный коммит был локальным, то есть история изменений была сохранена только в вашем локальном репозитории. Для того, чтобы передать изменения в репозиторий расположенный в ~/repos/hgproject выполним:

> hg push
pushing to ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

После выполнения этой команды все изменения зафиксированные в локальном репозитории были зафиксированы также и в удаленном. Теперь склонируем репозиторий ещё раз, и посмотрим как происходит обмен ревизиями в Mercurial. Создадим новый каталог ~/projects/hgproj_clone, и склонируем в него наш удаленный репозиторий:

>hg clone ~/repos/hgproject ~/projects/hgproj_clone
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

И уже во вновь склонированном репозитории создадим файл other.txt с помощью вашего любимого текстового редактора.  И снова повторим операции описанные выше:

> hg status
? other.txt
> hg add
adding other.txt
> hg commit
> hg log
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории


changeset:   0:8fae369766e9
user:        mike@mike-notebook
date:        Fri Nov 27 08:58:01 2009 +0300
summary:     Файл readme.txt добавлен в репозиторий

Видим, что в новом репозитории отражени как изменения сделанные локально, так и изменения сделанные в удаленном репозитории, которые мы ранее отправляли командой push. Теперь воспользуемся еще одной командой:

> hg outgoing
comparing with ~/repos/hgproject
searching for changes
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории

По команде hg outgoing Mercurial выводит список ревизий которые есть в вашем локальном репозитории, но которых нет в «центральном». Отправим появившиеся ревизии в «центральный» репозиторий известным нам способом:

> hg push
pushing to ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

Итак, в «центральном репозитории две ревизии. Теперь научимся забирать обновления из центрального репозитория. Для этого перейдём в каталог с первым клоном, то есть в ~/projects/hgproject, и скажем:

> hg incoming
comparing with ~/repos/hgproject
searching for changes
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории

Команда «hg incoming» выдает список ревизий, которые есть в удаленном репозитории, но отсутствуют в локальном. А затем получим эти ревизии, для чего скажем:

> hg pull
pulling from ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)

Команда «hg pull» получает ревизии из удаленного репозитория, и добавляет их в локальный, таким образом, изменения из нашего «центрального» репозитория были перемещены в  локальный репозиторий. Но они остались только в репозитории, локальная копия осталась нетронутой. Для того, чтобы обновить локальную копию скажем:

> hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Если посмотреть на состояние рабочей копии, то она соответствует состоянию рабочей копии в репозитории ~/projects/hgproj_clone, а состояние хранилища во всех трех репозиториях одинаково.

Ну и напоследок просто необходимо сказать о ещё одной команде. «hg help», как вы уже, наверное, догадались выводит некоторый набор подсказок по работе с утилитами Mercurial. А при использовании в виде «hg help [command]» выводит подсказку о приемах работы с указанной командой. Причем это именно краткая подсказка, если вам требуется подробное описание, то лучше всего обратиться к документации, которая имеется в абсолютно свободном доступе и вполне неплохого качества.

Итак мы познакомились с основными приемами и командами работы с распределенной системой контроля версий Mercurial. Главным отличием, проявившихся на данном этапе, от централизованных систем контроля версий является наличие полной копии всего репозитория у каждого пользователя, что приводит к двухступенчатой системе взаимодействия с хранилищами (commit-push/pull-update). Такая двухступенчатая система требует некоторого привыкания, однако она вполне понятна и логична, и, на самом деле, достаточно проста в использовании. На этом я заканчиваю этот раздел. В следующем разделе мы рассмотрим наиболее интересные аспекты взаимодействия с Mercurial, а именно ветвления (branching) и слияния (merging).

Документация Django в chm и pdf формате

Нарыл сегодня документацию для django, да и не только, для того чтобы использовать на ноуте. У меня часто нет интернета на ноуте, и я далеко не все помню из документации, что вполне естественно. А Django-book не совсем нравится, там не все есть, в документации которую рекомендуют использовать на сайте чёрт ногу сломит - всё таки 21 век, а там txt файлы. Вот, малец погуглив, накопал тут.

Введение в Mercurial. Часть 1. Распределенные системы контроля версий (DVCS).

Здравствуйте, уважаемые!

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

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

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

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

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

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

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

Смотря на такую структуру, возможность локальных коммитов, возможность синхронизации состояния репозитория с кем угодно создается ощущение, что исходники превратятся в кашу, и на определенном этапе, причем совсем недалеком от начала, уже невозможно будет как-то получить адекватное их состояние. На самом деле все не так страшно. Мощнейшей вещью распределенных систем контроля версий - является ветвление. При этом это не ветвление Subversion, это действительно настоящее, удобное и понятное ветвление и слияние. В DVCS, ну по крайней мере в Mercurial (хотя догадываюсь что и в Git и в Bazaar) ветвление это повседневная операция, это в принципе основа контроля версий в данном случае. И реализована она абсюлютно логично и понятно, и действительно проста в использовании.

Для меня решающим фактором при принятии решения о переходе на Mercurial стали именно локальные коммиты (у меня не всегда есть доступ к интернету, а иногда возникает необходимость что-то закоммитить) и настолько мощная поддержка ветвления. Но уже после перехода я был немало удивлен скоростью работы с репозиториями, эквивалент checkout работает очень быстро даже на сверхбольших репозиториях, commit и update - это моментальные операции, действительно моментальные.

Как работать со всем этим хозяйством я буду постепенно писать в следующих постах. Сегодня этакое начало. Следующий пост будет как раз про основы работы с Mercurial. Для тех кто знаком с Subversion не составит труда сделать первые несколько шагов в этом направлении.

Продолжение. Часть 2. Основы работы.

Установка и настройка системы контроля версий Mercurial на сервере

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

После часа гугленья нашлось одно решение, которое отвечало всем требованиям - использовать Apache в связке с Mercurial, при помощи hgwebdir.cgi из стандартного комплекта Mercurial. Итак, предположим что на сервере стоит Apache2 и Mercurial. Если этого нет, то нетрудно воспользоваться apt-get (у меня на серваке Debian), или пакетным менеджером своей системы. Отмечу только, что для выполнения всех требований нужна версия Mercurial не меньше 1.2.1, так как только в этой версии была исправлена ошибка, которая не позволяла разделять права на чтение различных репозиториев стандартными средствами.

Итак, основные задачи, которые предстоит решить:

1. Настроить Apache

2. Настроить hgwebdir.cgi

3. Создать и настроить репозиторий

 Поехали с начала. Я разместил корневую папку репозитория в папке /home/mike/www-data/hg/. Чтобы не путаться я на сервере все собственные данные размещаю у себя в домашней папке. В конфиг соответствующего виртуалхоста добавляем описание:

Alias /hg "/home/mike/www-data/hg"
  <Directory "/home/mike/www-data/hg/">
     Order allow,deny
     Allow from all
     AllowOverride All
     Options ExecCGI FollowSymLinks
     AddHandler cgi-script .cgi
  </Directory >

В данном случае предполагается, что все репозитории будут доступны по ссылкам вида http://[домен]/hg/[репозиторий]. AllowOverride необходим для возможности использования .htaccess файла, далее он потребуется. Создаем в каталоге /home/mike/www-data/hg/ файл .htaccess примерно такого содержания:

RewriteEngine On
RewriteBase /hg
RewriteRule ^$ hgwebdir.cgi  [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) hgwebdir.cgi/$1  [QSA,L]

AuthUserFile /home/mike/www-data/hg/htpasswd_hgstore
AuthGroupFile /dev/null
AuthName "HgRepo"
AuthType Basic
Require valid-user

Аутентификацию организуем срествами HTTP, логины и пароли будут храниться в файле /home/mike/www-data/hg/htpasswd_hgstore, как и написано в .htaccess. А в первой части указаны директивы для mod_rewrite (который естественно нужно подключить), которые позволяют получить красивые урлы вида http://[домен]/hg/[репозиторий], без указания hgwebdir.cgi. Правда описанный выше способ имеет свои недостатки - поле [репозиторий] в url не может совпадать с именем каталога на диске.

Идем дальше. В папку /home/mike/www-data/hg/ копируем файлик hgwebdir.cgi (в Debian он находится в /usr/share/doc/mercurial/examples/), и разрешаем ему выполняться:

chmod +x hgwebdir.cgi

Создаем в этом же каталоге файл hgweb.config, в котором прописываем следующее:

[paths]
test = repo_test

[web]
baseurl = /hg

Главное здесь - секция [paths]. В ней прописываются соответствия урлов и репозиториев на диске в виде URL = /path/to/repo, где /path/to/repo считается от текущего по отношению к hgweb.config каталога, а URL - от алиаса /hg/.

Нам потребуется ещё один файлик, а именно hgrc, который тоже создаем в каталоге с hgwebdir.cgi, и в этот самый hgrc вписываем:

[web]
#allow_push = *
#allow_read = *
push_ssl = false
contact = Mike Girkin
description = Get our elephants
allow_archive = bz2 gz zip
style = gitweb

Это заготовка для hgrc в каждом из репозиториев. Осталось дело за малым - создаем репозиторий, и копируем заготовку hgrc по месту:

mkdir repo_test
cd repo_test
hg init
cp ../hgrc repo_test/.hg/

Осталось только создать файлик с паролями htpasswd_hgstore с помощью утилиты htpasswd, и вбить в него нужное количество пользователей и паролей. Ограничить доступ на чтение/запись можно с помощью директив allow_read/allow_push в файлах hgrc лежащих в каждом из репозиториев, например:

allow_read = pupkin petrov sidorov
allow_push = petrov

Обращаю внимание, что в директивах allow_read/allow_push используются те логины, которые забиваются в htpasswd_hgstore, и используются для аутентификации клиентов. Для того, чтобы открыть доступ всем аутентифицировавшимся пользователям пишем allow_read = * или allow_push = *, соответственно.

И последнее, что нельзя забыть сделать, это поменять владельца для всей ~/www-data/hg/ (у меня Apache выполняется от имени www-data:www-data):

chown -R www-data:www-data ~/www-data/hg

На этом, для первого репозитория все настроено, и он должен быть доступен (в данном случае по ссылке http://[домен]/hg/test/, при этом он доступен как для утилиты hg и клиентов по этому url, так и через браузер, хотя необходимость последнего очень спорна.

Чтобы добавить новый репоиторий необходимо выполнить следующее:

1. Создать каталог (mkdir repo_new)

2. Прописать в hgweb.config в секцию [paths] соответсвие путей (new = repo_new)

3. Скопировать hgrc в repo_new/.hg/

4. Прописать во внутренний hgrc пользователей, которым разрешены операции над репозиторием

5. Изменить владельца на www-data (chown -R www-data:www-data repo_new)

На этом все. Спасибо за внимание ;)

Отличие между оператором "as" и операцией приведения типа

Это перевод оригинальной статьи находящейся здесь. Все права на оригинал принадлежат автору.

Большинство разработчиков скажут вам, что разница между «(Alpha) bravo» и «bravo as Alpha» состоит в том, что при ошибке приведения типа в первом случае будет выброшено исключение, тогда как во втором случае будет возвращен null. Хотя это действительно так, и это наиболее очевидное отличие, оно не единственно. Есть несколько подводных камней, которых нужно остерегаться.

В-первых, поскольку результатом оператора «as» может быть «null», тип результата должен быть таким, чтобы он в принципе мог принимать значение «null», то есть быть либо ссылочным типом, либо «nullable». Невозможно выполнить «as int» – это бессмысленно. Если аргумент окажется переменной не приводимой к типу «int», то каким же тогда должно быть возвращаемое значение? Так как результат операции «as» может принимать значение «null», то переменная, которой он присваивается, должна быть именованного типа.

Во-вторых, оператор приведения типа cast, это довольно странный зверь. Это связано с двумя противоречащими друг другу действиями: «проверь, действительно ли этот объект заданного типа и выбрось исключение, если нет» и «этот объект не того типа, что указан – найди мне эквивалентное значение указанного типа». Последнее означает, что оператор «cast» не выполняется оператором «as». Если вы напишете:

short s = (short)123;

int? i = s as int?.

вам не светит удача. Оператор «as» не выполнит преобразование, изменяющее представление, из «short» в «nullable int», как бы это сделал оператор приведения типа. Похожим образом, если у вас есть класс Alpha и не связанный с ним класс Bravo, с определённым пользователем преобразованием из Bravo в Alpha, операция «(Alpha) bravo» вызовет заданное пользователем преобразование, а «bravo as Alpha» – нет. Оператор «as» подразумевает только преобразования ссылок – упаковку (boxing) и распаковку (unboxing).

И последнее. Несомненно, случаи применения эти двух операторов внешне похожи, но по смыслу (семантически) очень различаются. Оператор приведения типа сообщает читателю: «Я уверен, что это преобразование корректно, и готов обработать исключение, если это не так». Оператор «as» говорит иное: «Я не знаю, корректно ли это преобразование или нет – давайте попробуем и посмотрим, что из этого выйдет».

Windows.Forms: ложимся в трей

Не так давно встала передо мной задача - уложить программу на C# в трей. При разработке использовались стандартный Windows.Forms из .net 3.5, хотя со времен .net 2.0 он практически не изменился. На моё счастье все оказалось очень просто. Попытаюсь объяснить основные шаги.
1. Размещаем компонент NotifyIcon на форме. У меня в приложении одна форма главная, остальные даже в таскбаре не отображаются, на главную форму и положил. NotifyIcon находится в ToolBox, вместе со всеми контролами... Параметры этого NotifyIcon говорят сами за себя, правда если не задать иконку, то в трее вообще ничего не появится :)
2. Маленько изменяем поведение формы. Для программ размещающихся в трее принято при сворачивании убирать окно из таскбара, а при щелчке на иконке в таскбаре - разворачивать. Поэтому пишем следующие обработчики:
- для сворачивания формы (эвент Form.Resize)

1. private void MainForm_Resize(object sender, EventArgs e)
2. {
3.     if (FormWindowState.Minimized == WindowState) Hide();
4. }

* This source code was highlighted with Source Code Highlighter.

- и для клика по иконке в трее (эвент NotifyIcon.Click)

1. private void notifyIcon_Click(object sender, EventArgs e)
2. {
3.     Show();
4.     WindowState = FormWindowState.Normal;
5. }

* This source code was highlighted with Source Code Highlighter.

3. Изменим поведение при попытке юзера закрыть окно по крестику. Для этого используем обработчик эвента Form.Closing:

1. private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
2. {
3.  if (e.CloseReason == CloseReason.UserClosing)
4.  {
5.     e.Cancel = true;
6.     Hide();
7.     WindowState = FormWindowState.Minimized;
8.  }
9. }

* This source code was highlighted with Source Code Highlighter.

То есть, при щелчке по крестику наша форма просто свернется вниз, а завершение программы будет отменено. Правда на текущий момент эту программу можно только прибить из менеджера задач, что не очень хорошо. Поэтому:
4. Сделаем контекстное меню для иконки в трее. Компонент ContextMenuStrip размещаем на нашей форме, создаем в нем пункт "Выход" (и какие ещё необходимо). Затем скажем нашему NotifyIcon, что у него есть контекстное меню с помощью свойства NotifyIcon.ContextMenuStrip. А обработчик пункта "Выход" у нас будет таким:

1. private void miClose_Click(object sender, EventArgs e)
2. {            
3.     Application.Exit();
4. }

* This source code was highlighted with Source Code Highlighter.

То есть CloseReason в данном случае будет ApplicationExitCall.
Вот и всё. Приложение должно вполне успешно справляться со своей задачей "лежания" в трее.

Генераторы в C# или "бесполезное" yield

Язык о котором пойдёт речь вышел достаточно давно, однако, судя по реальному опыту общения, мало кто пользуется всеми имеющимися возможностями. Этот пост я посвящу ключевому слову yield в языке C# 2.0.
Сначала несколько слов о тенденциях развития С#. Вспоминая каким был C# 1.0, могу сказать, что это была калька с Java2SE, причем не сказать что удачная. Чистый ООП язык, практически слизаный с Java, без какой-либо собственной красоты и лоска, без своего шарма. Однако уже вторая версия очень сильно порадовала своими возможностями, а именно некоторым движением в сторону функционального программирования. Эта же тенденция существенно продолжается и в третьей версии (VS2008), в C# 4.0 (VS2010) функциональные возможности будут расширены ещё больше, при этом Microsoft добавляет в платформу .NET полноценный функциональный язык, который много лет разрабатывался Microsoft Research. По-моему говорит это о многом.
А теперь к делу!
Ключевое слово yield изначально было предназначено для облегчения разработки классических итераторов .NET, а именно классов, реализующих интерфейсы IEnumerator<T> и IEnumerable<T>. То есть, разработка своей коллекции, или способа обращения к существующей коллекции требовала разработки как минимум одного класса - итератора с интерфейсом IEnumerator<T>, по одному классу на каждый способ прохода коллекции. Довольно муторное и однообразное занятие.
И тут к нам на помощь приходит yield!
Небольшой пример. Пусть нам хочется получить все элементы списка находящиеся в диапазоне [3;5]. Вместо стандартного for напишем следующий кусок:

IEnumerator<int> GetIntervalled(List<int> Collection)
{
for(int i=0;i<Collection.Count;i++)
{
if(Collection[i]>=3 && Collection[i]<=5) yield return Collection[i];
}
}

Использовать только что написанный код можно как и обычно используются итераторы – foreach. При очередном выполнении yield return функция вернет управление вызывающей, и передаст соответствующий элемент. На самом деле компилятор по этому коду создаст виртуальный класс реализующий интерфейс IEnumeratot<t>, но нас это не должно интересовать. Подобная конструкция есть первый, маленький шажок в сторону функционального программирования – это один из вариантов продолжения (continuations), потому что визуально код, при повторном вызове, продолжает выполняться с того места где выполнение было окончено. Подобная конструкция в некоторых языках программирования (откуда она и была заимствована) называется генератором, отсюда и название заголовка :)
Конечно, приведенный выше пример абсолютно неинтересен, и ничем не отличается по смыслу от примера, приводимого в документации. Понять, зачем применять столь хитрую конструкцию крайне тяжело. Для того, чтобы стало немножко больше понятно зачем нужны такие вещи приведу пример из реального кода.
В формочку (Windows.Forms) выводятся некоторые сущности, а пользователь отмечает галочками те, которые ему необходимы. Мне хотелось получить отмеченные галочкой сущности, yield пригодился как нельзя кстати:

public IEnumerable<DatabaseImportCase> SelectedImportCases
{
get
{
for (int i = 0; i < lbImportPackages.CheckedIndices.Count; i++)
{
yield return ShownImportCases[i];
}
}
}

ShownImportCases – это список отображаемых сущностей, lbImportPackages – листбокс с галочками (CheckedListBox), в котором отображаются эти сущности. Естественно предполагается, что индексы отображаемых на форме и хранимых в памяти сущностей совпадают. Операции по получению элементов происходят с помощью «ленивых вычислений», то есть получение очередного элемента произойдет только тогда, когда вы его потребуете. Никаких виртуальных списков в памяти не строится. Итак, yield – это универсальный, очень удобный способ получения новых, произвольных по сложности итераторов. Основное его преимущество – уменьшение количества не имеющего смысловой нагрузки кода. То есть, использование этого приема, это просто syntax sugar, но вряд ли кто откажется от сладкого :) Безусловно появление LINQ, а именно LINQ to Objects существенно снизило ценность yield, поскольку практически все итераторы можно получить с помощью запросов LINQ, однако понимание работы такого рода продолжений крайне необходимо для понимания более сложных конструкций функционального программирования. Которые я постараюсь рассмотреть в одном из следующих постов.

Наследование шаблонов в Django

В питоновском веб-фреймворке django встроен механизм наследования шаблонов страниц. Лично я считаю, что это очень спорная фишка и должна применяться с большой аккуратностью. Сейчас попробую объяснить почему.
Сначала определимся с терминологией. Этот механизм является именно наследованием, тем самым, которое используется в ООП. Этот вывод я сделал проанализировав получающиеся конструкции. Ведь фактически шаблон-наследник знает о структуре шаблона предка, хотя может и не знать детали реализации, ведь для того, чтобы переопределить (или доопределить) часть исходного шаблона нам потребуется указать имена тех частей, которые необходимо переопределить. Итак, рассмотрим маленкий пример:

Родительский шаблон:

<html>
<head>
<meta equiv="Content-type" content="text/html; charset=utf-8" />
<link type="text/css" rel="stylesheet" href="/static/Styles.css" />
{% block extrahead %} {% endblock %}
<title>{% block title %} {% endblock %}</title>
</head>
<body>
{% block content %} {% endblock %}
</body>
</html>

Шаблон наследник:

{% extends "base.html" %}

{% block extrahead %}
<script type="text/javascript" src="additionalscript.js"></script>
{% endblock %}

{% block title %}
Супер заголовок
{% endblock %}

{% block content %}
...
{% endblock %}

Казалось бы все по джанговски и замечательно. Но! Работа с шаблонами реализованная таким образом таит немало неприятностей, но самая главная из них - шаблон более низкого уровня по иерархии знает о структуре шаблонов более высокого уровня. И не просто знает (что не стало бы проблемой при использовании подходящих конвенций), а просто обязан использовать эти сведения. Получается что шаблон более низкого уровня сильно связан с более абстрактным шаблоном, что не есть правильно и лишает подобную структуру гибкости.
Выход? Есть выход! Наследование шаблонов безусловно мощная вещь и позволяет избежать дублирования кода, но использовать её необходимо с аккуратностью, особенно в больших проектах. Использовать также, как и наследование ООП, проверяя действие принципов используемых в ООП. Лично я для себя проверяю возможность наследования отношением "является", наследование можно применять в случае, если в человеческом языке корректной будет фраза "<наследник> является <предком>". Таким образом, приведенный выше пример корректен, так как шаблон-предок, фактически, является "обобщенной страницей", а шаблон наследник - "конкретной страницей". Но в случаях добавления дополнительных элементов на страницу, контролов и прочего, на мой взгляд более правильным и менее пахнущим будет использование агрегации с использованием механизмов custom tags.