Поддался я влиянию моды и захватывающим перспективам DVCS с недавних пор. Это вытолкнуло меня с наезженной колеи Subversion + Trac и заставило искать новые схемы как хранить исходные тексты в разных компаниях. И предоставлять для них удобный доступ разработчикам, заказчикам и другим заинтересованным личностям.

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

Само собой, Bitbucket — наше все. Но у любого разработчика есть закрытые проекты, которые в паблик выкладывать не хотелось бы. Можно, конечно, платить $50 в месяц за возможность хостить 25 проектов на bitbucket'е. Я лично считаю, что лучше эти деньги потратить на dedicated сервер и поднять себе сколько угодно проектов. Будет не так удобно, но зато свое и с возможностью тюнинга, бекапа и других вкусностей.

DevConf — профессиональная конференция, посвященная ведущим технологиям программирования и веб-разработки.

Мы продлили прием докладов до 12 апреля — талантливые спикеры и фанаты — WELCOME!
http://devconf.ru/offers

Программа мастер-классов
18 мая (вт) — на целый день

Осеннее обновление Хабрахабра, к нашему общему сожалению, обладает множеством убедительных признаков сырого кода (прочтите их и дополните в комментариях, если я чего-то не заметил или пропустил):

Так уж сложилось, что до недавнего времени все проекты, написанные мною на Java я собирал, кхм, за меня собирал NetBeans. И меня такой расклад вещей вполне устраивал: после сборки всего проекта всё аккуратно складывалось в директорию dist со всеми подвязанными библиотеками, оставалось накидать туда пользовательской документации, необходимых native-библиотек (например от Firebird) и в путь, т.е. всё в архив. Когда то я делал это вручную, потом велосипедом, а потом уже Maven'ом. Под катом находится история о том, как же я пришел в стан maven и что из этого получилось.

 

Статистика Debian позволяет вполне объективно сравнить популярность различных систем управления версиями. Git на графике обозначен зелёным цветом.


^{Количество инсталляций систем управления версиями за 2004-2011 гг}

Статистика собирается с пользователей, которые установили пакет popularity-contest (popcon). После установки popcon еженедельно отсылает в Debian по электронной почте информацию об установленных в системе пакетах и времени последнего использования.

Данный зверь будет полезен тем, кто не пользуется GUI утилитами при работе с git, mercurial и т.д., а чувствует себя комфортно работая с ними из консоли.
vcprompt.com — python скрипт, который будет выводить основную информацию по версии VCS в текущей директории, если такова есть. Как то название VCS, текущую ветку, были ли изменения с последнего коммита и ещё несколько параметров, которые можно задать в формате вывода.

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

Кроме того, т.к. я разрабатываю на django, и сайты запускаю под этой же связкой, есть и четвёртая причина — унификация, а она очень полезная вещь.

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

Несколько дней назад передо мной поставили задание — поднять mercurial-репозиторий на одной из локальных машин, и поставили одно условие — обязательная авторизация по SSH. Установка будет производится с использованием Mercurial Server на 64-битной серверной Убунте.

Как ни странно, но среди программистов ещё довольно много тех, кто не видит смысла в системах контроля версий (СКВ) или попросту не знает о них. Хватает и тех, кто знает, но не в курсе с чего начать внедрение или, при использовании, проходят мимо очень удобных возможностей.

Введение

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

Цели

• Создание, изменение, удаление репозиториев Mercurial, используя web интерфейс.
• Добавление и удаление пользователей, разграничение доступа, смена паролей, используя web интерфейс.
• Отслеживание ошибок и распределение задач, используя web интерфейс.
• https повсеместно.

При клонировании репозитория с помощью команды

hg clone A B

mercurial сначала пытается создать жесткие ссылки для файлов внутри папки .hg в новом репозитории. Это ускоряет клонирование и экономит место на жестком диске.

Жесткие ссылки поддерживаются файловыми системами Linux и Windows NTFS. Для файловых систем, которые не поддерживают жесткие ссылки (например Windows FAT), а также при клонирование через http/https или ssh с удаленного сервера mercurial полностью копирует все файлы.

Вероятно, у каждого разработчика есть рабочая папка с чекаутами (svn) и клонами (git, hg) разных проектов. Называют ее по разному: workspace, work, src и т.д.

Бывает ли такое, что Вы забываете закоммитить или запушить изменения в рабочих директориях? Даже если ответ — не часто, но бывает, то Вам стоит познакомиться с утилитой unpushed. Она помогает поддерживать рабочую папку с проектами всегда в чистом и консистентном состоянии.

Например, у меня в папке ~/workspace около 20-ти проектов от разных репозиториев. По каким-либо причинам я хочу этот workspace удалить. Перед этим нужно проверить, точно ли все закоммичено. В ручную сделать это не очень то и быстро. Так и родился этот скрипт.

Под катом краткий обзор программы.

На хабре уже было много статей о распределенных системах управления версиями (DVCS), их сравнений, а также сравнений GUI-клиентов для них. Также были обсуждения плагинов к IDE для работы с git и mercurial. Но практически не было информации об инструментах визуального сравнения и разрешения конфликтов слияния.


Недавно я «перескочил» с mercurial (который до сих пор считаю более удобным и логичным) на git, потому что, подавляющее большинство проектов, которые мне интересны, используют git и хостятся на github. В связи с этим, встал вопрос о пересмотре арсенала инструментов, в частности вопрос выбора инструмента визуального сравнения и слияния (diff and merge). Дабы восполнить недостаток информации на хабре, я решил написать этот мини-обзор. Как говориться — по горячим следам.

Под катом Вы также найдете примеры настроек Git для использования с DiffMerge и WinMerge под Windows. Думаю многим сэкономит время.

Bitbucket — это хостинг для Mercurial и Git репозиториев. Ближайший аналог и прямой конкурент — github. По популярности Bitbucket отстаёт, однако у него есть пара заметных фич по сравнению с github — это поддержка Mercurial и возможность создать сколь угодно приватных репозиториев на бесплатном аккаунте, однако дать доступ можно максимум пяти пользователям (у github вообще нет приватных репозиториев для бесплатных аккаунтов).

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

Обзор кода полезен и делать его можно разными способами: патчами по почте, сидя рядом лицом к лицу или используя специализированные инструменты/плагины. Каждый способ имеет свои плюсы и минусы, однако мы предлагаем ещё один, который позволяет нам использовать то, что у нас уже есть.

 

Часто ли вам приходилось просматривать список изменений что бы понять — затронуло ли оно вас?
Хотели бы вы бегло просмотрев комментарий знать всю необходимую информацию?
Хочу поделиться сокращениями устоявшимися в нашей команде.

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.