Subversion всегда был удобен такими фичами как, атомарные commits, версионированные директорий, хорошая поддержка бинарных файлов, быстрое создание бранчей и тагов, поддержка нескольких сетевых протоколов, в том числе и HTTP. Но, чего действительно раньше не хватало в subversion, так это возможности найти какой код был смержен, откуда он мержился и когда это произошло. Отсутствие такой возможности приводило раньше к трудностям при мерже:

К примеру, пользователь не сможет смержить изменения с 11 по 17 ревизию в бранч, если он уже мержил 11 и 13 ревизии в бранч ранее. В новом subversion мержи логируются и нет больше необходимости записывать на листик, какой код, когда и откуда мержился.

Разработчики subversion как будто услышали мои мольбы и добавли change lists –функционал, позволяющий ассоциировать произвольные файлы с неким человекочитаемым именем. К примеру вы работаете над несколькими багами одновременно, и по окончании одного из них хотите залить его в репозиторий. А файлы, относящиеся к другому фиксу – оставить в локальном репозитории. Раньше приходилось прибегать к помощи листика, чтобы разделить эти два набора файлов и залить только нужные файлы. Теперь проассоциировав первый набор файлов с неким именем, вы можете по окончанию работ просто указать имя этой группы файлов и они немедленно попадут в основной репозиторий.

Еще одна полезность, появившаяся в 1.5 subversion – это sparse checkouts, позволяющий выполнять основные операции только над указанными уровнями дерева каталогов. Это удобно, если вы не хотите “слить” только текущий каталог со всеми файлами в нем, но не хотите “сливать” все его поддиректории. 

Также было добавлено интерактивное разрешение конфликтов – теперь svn сам предлагает варианты решения конфликта. Лично для меня эта фича никакой погоды не делает, так как я давно пользуюсь Araxis Merge, чего и вам советую.

Не знаю почему, но большинство GIT’овцев кричат: SVN sucks, попробуйте GIT – у нас проект в жите 2.5 гига и ничего не тормозит. У меня, я вам скажу, есть проект около 4 гигабайтов в архиве. То есть сжатый RAR’ом. И я никаких тормозов не наблюдал еще с версии 1.4.6. А в версии 1.5 ускорена работа из-за простого трюка – они сделали более многовложенную файловую систему, т.е. в одной директории такого дикого количества файлов уже не будет. И это важно, особенно, если ваш сервер хранит репозиторий на Network Attach Storage с не самой продвинутой файловой системой, которая тормозит при 10 000 файлов. Из-за того что в subversion файлы readonly, это позволяет улучшить стратегию кэширования на стороне NAS’ов и других умных файловых систем. Теперь неизменяемые файлы сгруппированны в каталоги, и вашей файловой системе можно сказать: вот эти каталоги неизменяемы (после появления файлов в ней) и ты пожалуйста это учти.

Разработчики клянуться, что теперь заработает CTRL+C!

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

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

Ссылки по теме

Subversion 1.5 Release Notes

Subversion: чеклист по правильным коммитам

Слияние: Руководство по ежедневному использованию

Merging and branching in Subversion 1.5

Subversion or CVS, Bazaar or Mercurial?

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

#1 Правильно ли вы поняли суть проекта?

Заказчики народ ленивый, а потому добиться от них подробной документации или спецификации будущего проекта непросто, особенно если проект небольшой. Зачастую менеджеры проектов получают, так называемую, user story. Потом этот документ усилиями менеджера или кого-то еще эволюционирует в спецификацию – более подробный документ с техническими терминами. И вот тут есть риск совершить первую, а зачастую и роковую ошибку – не поделиться этим документом с заказчиком. Ведь заказчик под словом “usability” имел ввиду не квадратную, а круглую кнопку! В лучшем случае такое недоразумение выльется вам в пару лишних часов работы, а в худшем – превышение бюджета/времени проекта, потеря/отказ от заказчика. Поэтому даже если вы и не планировали составить что-то похожее на спецификацию, то по крайней мере выслать скриншоты аналогов или описание проекта своими словами – было бы хорошим шагом в сторону от этих граблей.

#2 Не слишком ли часто, вы общаетесь с заказчиком?

Согласен, несколько противоречивый момент. В предыдущем пункте я рекомендовал дополнительно общаться с заказчиком, а теперь намекаю на то, что это не всегда полезно. Это действительно так. Наиболее плотное общение полезно в начале проекта, когда каждый участник, в том числе и заказчик пытаются понять и “построить” проект у себя в голове. Но дальнейшее общение по 2–3 часа в день может губительно сказаться на проекте, ведь во время этих дискуссий у заказчика появляются множество новых идей, не предусмотренных ни бюджетом, ни архитектурой проекта. Ежедневные вопросы “А в каком состоянии сейчас проект?”, “А кто над чем работает в данный момент?” и т.д. не только вызывают раздражение, но и отнимают и без того драгоценное время. И даже если заказчик отвлек вас всего на мгновение вопросом “А как пройти в библиотеку?”, то вам понадобиться от 10 минут до часа времени, чтобы вернуться в рабочее русло и восстановить свою производительность. Поэтому, если вам позовляет ситуация, ограничтесь общением по почте, оставьте номер телефона на пожарный случай – и никаких мессенджеров! Тем не менее онлайн общение необходимо на любом проекте – организуйте это в виде заранее спланированных коференц-звонков или собраний с точным регламентом по времени.

#3 Позволяете ли вы заказчику саботировать проект?

Заказчик может саботировать проект множеством способов – вносить в проект новые идеи или функционал; указывать вам как именно необходимо реализовывать ту или иную часть проекта; сокращать сроки сдачи работы и так далее. Был у меня один проект, на котором мы выполняли любую прихоть заказчика, крутили архитектурой проекта так, что через месяц ее было просто не узнать. А сам проект из узконаправленного решения превратился в некую платформу для решения “всех” проблем, в том числе и глобального потепления. Во время этого процесса заказчик был доволен как слон таблеткой, но как только подошло время первой бета-версии – он взгрустнул… Взгрустнул оттого, что бета не вышла, ведь последний месяц мы писали не запланированный функционал, а переделывали проект под новые идеи заказчика. В итоге все остались в проигрыше – мы без заказчика, заказчик – без продукта. Мораль проста – научитесь говорить НЕТ, даже если вы хотите угодить вашему клиенту.

#4 Дело дошло до спора?

Не все заказчики обладают техническими знаниями, но почти все уверены, что они умнее вас. Именно поэтому деньги платят они, а не наоборот. Спроить в такой ситуации довольно тяжело – кто платит, тот и заказывает музыку. Но что, если это может привести к краху проекта и заказчик вместо джаза получит рок? Мне не раз приходилось наблюдать, как специалисты с многолетним опытом шли наповоду у заказчика лишь бы не брать всю ответственность за долю проекта на себя. Но в итоге заказчик все равно обвинял их, когда проект начинал разваливаться на части… Идеальным вариантом будет найти третий источник информации, желательно довольно авторитетный, который бы подтверждал ваше мнение или предложение. Но если вам всеже пришлось согласиться с заказчиком, то постарайтесь сразу перенести ответственность за это решение на него и объяснить каким образом это может отразиться на проекте в будущем.

#5 Что вы делаете, когда клиент недоволен?

Пытаетесь оправдаться? Перенести вину на заказчика? Доказать, что всему виной фаза луны? Все это, безусловно, пути решения проблемы, по которым иногда приходится идти. Но зачастую, наилучшим способом вернуть заказчика в прежнее, довольное состояние – это показать, что вы с ним одна команда и находитесь по одну сторону баррикад и, что вы заинтересованы в решении возникшей проблемы не меньше его самого. Даже если бюджет уже исчерпан, время подходит к концу, то фраза “да, это проблема, но мы поможем вам ее решить” заставит смотреть на вас с благодарностью. А следующая фраза “…но на это нам нужны будут новые $” будет звучать не так удручающе, как фраза “это не наша, а ваша проблема. Денег больше нет, помочь ничем не можем.”

И что с того?

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

Именно так – The Bug – называется "новая" книга Ellen Ullman. Не буду пересказывать содержание книги, просто оставлю две фразы из этого произведения искусства:

"Programming starts out like it's going to be architecture-all black
lines on white paper, theoretical and abstract and spatial and
up-in-the-head. Then, right around the time you have to get something
fucking working, it has this nasty tendency to turn into plumbing.

...

It's more like you're hired as a plumber to work in an old house
full of ancient, leaky pipes laid out by some long-gone plumbers who
were even weirder than you are. Most of the time you spend scratching
your head and thinking: Why the fuck did they do that?"

Как это ни парадоксально, но многие из нас работают для того, чтобы не работать. То есть стараются заработать столько денег, чтобы нужды работать больше не было. И дело тут совсем не в человеческой лени или в тяге получить статус богатого человека, а в стремлении заниматься тем, что нравиться. Тем не менее, придя на «нелюбимую» работу многие из нас все же делают то, за что им платят деньги – работают. Так откуда же берется это сокровенное желание поработать? Можно ответить просто – человеком движет инстинкт самосохранения, и в условиях рыночных отношений, для выживания необходимо где-то брать деньги. Все это верно, но есть один момент – даже движимый инстинктом самосохранения человек разумный(homo sapiens), придя на работу зачастую, лишь делает вид, что работает или, по крайней мере, осуществляет ее не в том объеме, в котором хотелось бы.

Многие компании вводят гибкий график, организовывают обеды, комфортно обустраивают офисы и многое другое только ради того, чтобы вам было приятнее работать. Делают они это не ради вашей широкой улыбки, а для того, чтобы вы лучше работали и не думали менять работу. Но правда в том, что ваша продуктивность практически не зависит от вашего настроения. Еще в далеком 1964 году Victor Vroom определил: настроение/продуктивность = 0,14. Это означает, что лишь 2% результата вашей работы были получены «благодаря» вашему хорошему настроению.  Но это вовсе не значит, что люди будут лучше также работать в условиях, приближенных к тюремным (хотя в Советском Союзе считали иначе…). Ведь обиженный или даже злой сотрудник может организовать настоящий саботаж на работе. Тут важна золотая середина – необходимо создать приемлемые условия труда и сконцентрироваться не на том, как улучшить настроение сотрудника, а на том, как увеличить его продуктивность:

Гибкий график. Позволяет сотруднику чувствовать себя свободным в своих действиях и самому строить свои рабочие планы. Абсолютная свобода в графике может привести к тому, что графики нескольких сотрудников не будут совпадать, и если их работа взаимосвязана, то продуктивность команды может пострадать. Как один из вариантов выхода из данной ситуации – зафиксировать хотя бы 4 часа рабочего времени.

Социальная или медицинская страховка. Тяжело сказать, влияет ли этот пункт соцпакета многих IT-компаний на продуктивность сотрудника…

Английский. Как один из видов профессиональных тренингов в IT-индустрии, это бесспорно положительно сказывается на продуктивности сотрудников.

Питание. Врядли «лишние» $3-$4 в день повысят продуктивность сотрудника. Более того, после определенного срока, сотрудник будет воспринимать это, как должное и не дай вам бог попытаться забрать у него эту «сладость».

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

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

К сожалению, многие IT-компании на рынке Украины не могут себе позволить посылать сотрудников на дорогостоящие профессиональные тренинги, выделять время на самообучение (или собственный проект, как это делает Google) или постоянно обновлять рабочие инструменты программистов. Проще нанять уже более квалифицированного, хоть и более дорого сотрудника. Но как говорил Dietrich Bonhoeffer: "If you do a good job for others, you heal yourself at the same time, because a dose of joy is a spiritual cure." - будем трудиться и все будет хорошо.

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

• Первое и самое главное - это безусловно опыт, потому что если вы уже реализовывали подобное в ваших предыдущих проектах, то вероятность того что ваша оценка совпадет с реальностью увеличивается.
• Далее необходимо  разбить будующий функционал на как можно более независимые блоки их можно разрабатывать в различных фазах проекта.
• Затем каждый блок разбивается на функционал, время реализации котрого не более 3х часов.
• Если какие-либо части настолько сложны или новы для вас, что вы не представляете себе как их реализовывать, то лучше потратить час-два на изучение/поиск подобных решений в гугле. Кстати,забыл сказать, что прежде чем вообще садиться оценивать проект, можно посмотреть не реализовывал ли кто-то другой, то что вы сейчас пытаетесь создать. Свой опыт ценне всего, но если есть чужой, то почему бы им не воспользоваться?
• Еще один момент - оценивать проект лучше не в одиночку(какой бы вы гуру ни были), а небольшой группой в 2-3 человека. Если количество людей будет больше, то будет слишком много мнений и тяжело будет быстро прийти к компромиссу, а следовательно быстро оценить проект (за оценку проекта заказчик как правило не платит...). Если людей будет меньше, а именно вы один, то есть риск переоценить или недооценить собственные силы.
• Но даже разбив проект на мелкие части и оценив каждую из них, мы не сможем получить точную оценку проекта(честно говоря получить точную оценку проекта невозможно в принципе), так как еще необходимо учесть человеческий фактор, а он предполагает чтот в рабочем 8ми часовом дне вовсе не 8 часов отдается работе:

  - Чтение блогов и новостей, разгребание почты по утрам. (15 минут в день)

  - Перерывы на кофе/чай. (2-3 в течении дня 10 минут на каждый)

  - Различного рода собрания. Проектные собрания для решения текущих вопросов. (дважды в неделю 3 часа)

  - Решение проблем с железом, не работает комп или сеть или нет тока. (раз в две недели пол дня)

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

  - Заполнение time journal-ов и других формальных документов. (15 минут каждый день)

  - Походы в WC. Да, это тоже занимает время. (10 минут в день. В дни когда селедку запиваешь с молоком 10 минут каждый час ;)

  - Написание необходимых емейлов (4 часа в неделю)

  - Написание ненужных емейлов (4 часа в неделю)

  - Удаление спама (30 минут в неделю)

  - Болезни, прочие личные причины отсутсвия на работе (1 день в месяц)

  - 8 минут - одна сигарета

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