Системы управления версиями *

В свое время озадачился добавлением в свою небольшую домашнюю сеть компактного сервера, для хранения и закачки медиа контента, 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 (девелоперская ветка).

Эта заметка будет интересна тем кто работает с subversion и должен переносить исходники из репозитория на сайт в «ручную», через консоль.
Не много предыстории.
Я достаточно часто обновляю файлы для нашего проекта Закладки на картинки (picfor.me) и для этого пользовался командой svn export …, но вот беда если мне надо закачать только изменения между ревизиями, то в консоли это сделать не так просто:

1. $ svn export  -r1123:1167 . /tmp/export_dir
2. svn: Revision range is not allowed

Есть конечно решений, если использовать клиента TortoiseSVN, вот статья с хабра где это описано.

Я же придумал решение для консоли.

Как сообщает Google Code Blog, в скором времени хостинг для опенсорсных проектов от гугла будет поддерживать Mercurial наряду с Subversion для контроля версий.

Разработчики тщательно выбирали между разными распределенными системами, и в конце концов остановили выбор именно на mercurial, а процессу выбора между mercurial и git посвящен этот интересный документ. Mercurial победил в «конкурсе», поскольку:

• он лучше интегрировался в инфраструктуру гугла: меньше сложностей с хранением данных, проще и «чище» HTTP интерфейс;
• удобнее для windows-пользователей ( официальный windows-порт git использует cygwin);
• кривая обучения менее, гм, кривая.

Гуглоразработчикам пришлось частично переписать mercurial, вместо стандартного дискового хранилища у них используется BigTable.

Простыми словами и с большим количеством картинок на примере Eclipse рассказывается, как сделать svn merge. Статья будет полезна тем, у кого выполнение слияния веток еще не стало повседневной частью работы.

 

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

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