Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

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

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.

 

HgAssist — repositories are synced!

Пользуясь системой управления кодом Mercurial мы часто сталкивались с тем, что забывали делать push после того, как в локальный репозиторий были сделаны комиты.

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

Поэтому мы написали HgAssist.

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

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

В свое время озадачился добавлением в свою небольшую домашнюю сеть компактного сервера, для хранения и закачки медиа контента, iTunes/UPnP сервера, backup своих проектов, TimeMachinе и.т.д.
В ходе чтения обзоров остановился на недавно вышедшей модели DS210j от Synology. В ходе переноса данных на NAS для хранения проектов решил установить Систему контроля версий — Subversion.
Если интересно добро пожаловать под кат.

Github наc заинтересовал с тех пор, как части проекта www.azati.com мы стали выпускать под AGPL лицензией. 1 апреля этого года Github объявил поддержку Subversion в режиме «только для чтения» для своих репозитариев. До сегоднешнего дня я был уверен, что это была первоапрельская шутка. Но вчера они объявили, что ввели поддержку Subversion еще и в режиме записи. Похоже Github целится в лидеры и настроен на пользователей которые уже устали от Subversion, но еще не созрели на Git. Ведь врядли те, кто уже использует Github с Git захочет использовать Subversion. Однако теперь многие поклонники Google code будут думать над переездом. Набор инструментов для работы с Subversion не меняется, глядишь, потом и Git можно попробовать ничего не теряя.

Краткая справка: Meld — утилита для визуального сравнения файлов/папок.

Наверняка не каждый согласится, что этот иструмент стоит тех танцев с бубном, которые необходимо совершить вокруг него для более менее комфортной работы (Meld слегка не расчитан на работу в Windows, но так как написан на python с использованием GTK, может функционировать и в ней). Я же, потыкав палочкой в бесплатные альтернативы, решил для себя, что если оно заведется, то усилия не будут напрасными.

Вышла новая версия распределённой системы управления версиями Mercurial и user-friendly клиента для этой системы — TortoiseHg.

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

Введение и отмазка

Доброго времени утра,

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

Если ещё не закрыли статью — обрисую ситуацию:

Что у нас есть

У нас есть nginx, mercurial несколько самостоятельных проектов, на каждый из которых имеется 3-4 репозитория. Ещё у нас иногда могут появляться сторонние разработчики, которым часть этих проектов показывать совершенно не обязательно.

Что со всем этим делать?

Кажись, я просёк то, что нигде никто явно не пытается писать — а мне без этого как-то непонятно было. У меня довольно большой опыт работы в VSS и некий опыт присматривания к SVN. А сейчас вот и к GIT-ам всяким присматриваюсь.

На страничке mercurial.selenic.com/wiki/UnderstandingMercurial в конце сказано, что если вы думаете держать в одном репозитории HG несколько родственных проектов, как привыкли в системах типа SVN, то лучше одумайтесь, ибо HG на это не рассчитан. Похоже это потому, что он всегда работает со всей рабочей папкой в целом.

Это хороший пример следствия из того, о чём я хочу сказать: у этих новомодных распределённых систем понятие дерево каталогов и файлов в рабочей папке ортогонально дереву её версий. Это есть второе (после наличия локального репозитория) ключевое отличие этих систем от предыдущих.

Введение

В статье рассматриваются несколько проблем (и полезных возможностей) при работе с mercurial и предлагаются варианты их решения.

Несколько проектов на одном фреймворке

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

Что же делать?

Доброго времени пребывания, уважаемые Хабровцы 8)
Наткнулся я недавно, на бескрайних просторах, на очень полезную и долгожданную штуковину. Что за штуковина — читай сабж.

Выглядит всё это, как всем известный TortoiseSVN для Windows. Только называется RabbitVCS и уже для Linux.
Если не верите, смотрите скриншоты :)

Спешу рассказать хабрасообществу о, относительно новом, дьявольски завораживающем проекте Gource которое еще не упоминалось. Это приложение позволяет визуализировать историю изменений в системе контроля версии. Отрисовывает невероятно красиво при помощи OpenGL.

Добрейшего.

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

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

 

Два года назад Линус Торвальдс рассказал представителям Google об использовании GIT (распределённой системы контроля версий) для ядра Linux. Посчитав, что многие могут пропустить эту интересную лекцию по причине незнания языка, я осмелился озвучить её по-русски.



а так же плейлист целиком.

Git это еще одна системы для управления исходным кодом, аналогичная subversion, cvs и другим. Почему аналогичная, а не «новая», «быстрая» и тп? SCM (source code management) прежде всего инструмент, который позволяет выполнять операции необходимые для одного разработчика и команды в целом. При каждый инструмент имеет свои достоинства и недостатки.

В этой статье мы сосредоточимся на основных функциях, без сравнительного анализа (чтобы не повторять миллионы заметок в web). И покажем пример, как применять git при работе с subversion.

Итак, сразу опишу нашу ситуацию и потом объясню почему дал этой статье такое глупое название :-)

Наша команда из 4х человек работает на одном проекте (пока не буду говорить, что за проект, надеюсь, напишу о нем позже)

У нас было 3 SVN ветки: Production (стабильная ветка, которая обслуживает запросы пользователей), Staging (промежуточная ветка), Trunk (девелоперская ветка).