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

Cruise Control — одна из достаточно большого количества CI (continuous integration) систем. Речь пойдет о том, как настроить ее для связи с SVN и деплоя сайта на .NET.

Для начала немного о задачах СС на данном сервере:

• Взять код из SVN репозитория
• Скомпилировать его
• Положить в директорию к IIS

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

 

Apache Software Foundation объявила о выпуске Subversion 1.7, но какие именно из новых возможностей 1.7 полезны пользователю? А почему бы вам не обновиться до версии 1.7? Под катом пять причин перехода на Subversion 1.7.

После двух с половиной лет разработки свет увидел новый major релиз централизованной системы управления версиями subversion: что нового, видео обзор.

• Скачать TortoiseSVN для Windows (GUI,CMD) или SlikSVN (только CMD)
• Скачать для OSX
• Для *NIX можем собрать из исходников сами.

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

Работая с svn нередко появляются моменты, когда во время коммита твой рабочий каталог становится неактуальным. При этом приходится обновлять свою локальную копию из репозитория и составлять коммит по-новой. Хорошо когда коммитить нужно всё, а если нужны лишь три файла из ста? В таком случае приходится по новой искать свои файлы. Хотя TortoiseSVN и упрощает жизнь в таких случаях, бережно сохраняя комментарий, но всё равно, время, потраченное на обновление каталога и получение дерева с удаленного SVN сервера не вернуть. Создатели TortoiseSVN упростили нам жизнь ещё больше, создав небольшую утилиту, речь о которой и пойдет в данной статье – CommitMonitor.

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

Вас могут смутить столь архаичный цифры в заголовке, однако, думаю, не я один до сих пор использую в работе w2k3 и mssql2000. Причина банальна: зачем что-то покупать, когда это куплено и работает. Дискуссию о недостатках/преимуществах w2k3 и w2008 предлагаю опустить. C другой стороны я не чужд прогрессу и в последнее время плотно использую в своей работе mercurial. И вот возникла необходимость поднять внутренний сервер, при этом в наличии имеется как раз таки оной из заголовка. Речь далее пойдет не о hg serve, а о полноценном hgweb. Статья возникла по причине того, что на то, чтобы заставить его работать, ушел целый день; при этом пошаговые инструкций на русском найдены не были. Да и английских не пруд пруди.

Методология изменения версий продукта программного обеспечения

   Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.

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

Краткая версия

Что предлагается: web интерфейс управления репозиториями и пользователями mercurial — hGate.
Кому полезно: тем, кто использует связку Mercurial+HgWebDir и создает репозитории или пользователей чаще, чем раз в пару месяцев.
Где скачать и как установить: bitbucket.org/shedar/hgate
Если Вам интересно, зачем это было делать, подробный перечень возможностей и что будет дальше — продолжаем.

Большинство разработчиков знакома с таким продуктом, как визуализатор code_swarm (на google code). Как минимум каждый третий наверняка выгружал для него лог и создавал видео, которое визуализирует процесс разработки приложения, в котором видно активность программистов. Ну и конечно каждый второй видел видео подобного рода. Практически все эти видео делались на срезе отношения программист⇨файл.
В этой статье будет описан процесс формирования лога в срезе отношения файл⇨строка, то есть с генерированное видео будет демонстрировать активность работы над файлом.

Кому это интересно под прошу под кат.
В статье будет использованы:

• Git — VCS
• code_swarm — визуализатор истории репозиториев.
• gource — визуализатор истории репозиториев.
• Эмулятор среды linux в Windows или UNIX OS (с git уже идет для win эмулятор msysgit)
• MEncoder — свободный кодировщик видео
• ffmpeg — программа для конвертации видео с использованием различных кодеков.

Не секрет, что по умолчанию изменение текста комментария к ревизии в SVN не разрешено. Пост предназначен для тех, кто хочет сделать это возможным, но не знает как.

Для работы с Mercurial под Windows нужен только TortoiseHG. Писать свои плагины для Mercurial не получится, но вроде большинство разработчиков их и не пишет. Во всяком случае я изредка пишу только скрипты для автоматизации. Если у вас Visual Studio, можно воспользоваться красивым плагином.

Локальные репозитории, команды на бумажке и прочая оставим для студентов и лабораторных работ, которых на весь интернет вагоны. Так как единственный бенефит Mercurial для простых смертных это работа в офлайне, этим и надо пользоваться. То есть, основной репозиторий создаём в онлайне: Mercurial сейчас поддерживает Microsoft и Google (вот удивительно!), поэтому апологеты могут выбрать любимую корпорацию без мучений. Но с одним нюансом, у MS не работает русский в комментариях к коммитам.

Предупреждение: Эта статья вас ничему не научит. Это очень высокоуровневый взгляд, мои мысли, моя рефлексия на вопрос, который для меня важен + небольшое этнографическое исследование по графическим клиентам git-а.

Поговорим о распределенных системах управления версиями.

CVS был грустным, медленным, неатомарным („ничего не трогайте, я коммичусь“), зато с нормальным клиентом в Эклипсе.

SVN был медленным и поначалу веселым, но с появлением первой ветки тоже грустным („ничего не коммитьте, я мержусь“), с двумя разными клиентами в Эклипсе, баги которых нежно дополняли друг друга.

Тогда я выучил git. Git — это такой нелогичный набор утилит командной строки, в котором ежедневные операции выполняются последовательностью из двух–четырех команд.

Не нашел хорошей «шпаргалки» по Mercurial на русском языке.

Предлагаю сделать свою.

Эта история началась много-много ревизий назад – тогда SVN Репозиторий был девственно чист, и ни один баг еще не осквернил его своим присутствием. Первые коммиты, первые откаты, просмотры лога – все это было так захватывающе, так ново. И разве мог Репозиторий тогда предполагать, что эти первые, такие приятные шаги впоследствии приведут его на хирургический стол?

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

Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»
• «Процесс слияния»

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

Часть 6. Архитектура репозиториев

Наш рецепт становится все лучше:

Несмотря на то, что распределенные системы контроля версий (Git, Mercurial, Bazaar) набирают все большую популярность, старый добрый Subversion по-прежнему широко используется. В данной статье я рассмотрю плюсы и минусы использования на практике внешних зависимостей (svn:externals) в SVN репозиториях.

Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»

Иногда при слияниях возникают конфликты. Обычно их легко разрешить. В любом случае их надо разрешить, или у вас будет несколько «голов». А кому это нужно?

Часть 5. Процесс слияния

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

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