Рубрика «Системы управления версиями» - 17

Выкладываю данную инструкцию, т.к. самому пришлось искать необходимую информацию по крупинкам. Инструкция рассчитана на людей, имеющих мало опыта в web технологиях и web разработке. Все программные комплексы настроены на выделенном под программистские нужды «сервере» под управлением Windows 7 Pro 32 bit.
Что имеем:

  • Visual SVN Server 2.6.0 (Apache Subversion 1.8.0 + Apache HTTP Server 2.2.25)
  • доступ к SVN уже настроен через ssl на порт 8443
  • Jira 6.0 с установленным плагином JIRA Subversion plugin
  • осуществлена базовая настройка JIRA Subversion plugin (в задачах отображаются соответствующие коммиты со списками файлов)
  • на SVN хранятся в том числе исходные коды, написанные на Delphi 7 с кодировкой CP1251

Что хотим получить:

  • просмотр содержимого коммитов
  • использование уже существующей системы авторизации SVN для доступа к исходному коду

Читать полностью »

mercurial-review-boardНекоторое время назад в компании, где я работаю в связи с расширением комманды было принято решение о введении процесса code review. Выбор инструмента пал на Review Board — продукт обладает достаточным функционалом, активно разрабатывается с 2006 года и является open source. В качестве системы контроля версий у нас используется Mercurial

О том, с чем какими задачами столкнулись при организации процесса код ревью для связки Review Board + Mercurial — под катом.
Читать полностью »

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

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

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

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

Решение написано на C#, использует API Amazon Web Services и показан пример настройки для Mercurial репозитория. Код открыт, ссылка будет в конце статьи. Все написано более или менее модульно, так что добавление поддержки чего-то кроме Amazon S3 не должно составить труда. Могу предположить, что для GIT настроить будет так же легко.
Читать полностью »

На Google Code запрещают размещение файловGoogle предупреждает, что вынуждена закрыть хостинг файлов на Google Code из-за «растущего количества случаев нецелевого использования сервиса» и для обеспечения «защиты и безопасности» пользователей.

Новые правила вступают в действие немедленно для новых проектов. Разместить файлы для новых проектов на Google Code теперь невозможно. Старые файлы в безопасности, и Google не планирует удалять их в обозримом будущем.
Читать полностью »

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

  • можно ли git «подстроить» под тот процесс разработки, который мне нужен?
  • будет ли менеджер и заказчик удовлетворён этим процессом?
  • будет ли легко работать разработчикам?
  • смогут ли новички быстро включиться в процесс?
  • можно ли процесс относительно легко и быстро изменить?

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

Читать полностью »

Вступление

В своей практике мне довелось участвовать в миграции проекта (codebase имел 5+ лет истории) с централизованной системы управления версиями (centralized VCS — SVN) на распределенную (distributed VCS — Mercurial). Подобные активности часто сопровождаются определенным количеством FUD (fear, uncertainty and doubt) среди команды, вовлеченной в этот процесс. Если технические моменты конвертации (структура новых репозиториев, инструментальная поддержка, работа с большими бинарными файлами, кодировки и т.п.) по большему счету будут решены в определенный момент, то вопросы, связанные с преодолением кривой обучения для команды для эффективного использования новой системы, на момент перехода могут только начинаться.

При таких переходах важно измение взгляда на новую систему контроля версий и ее использование (mindset shift). Тут очень помогает хорошее понимание принципов, на которых основаны VCS. Если разобраться в основах, использование системы заметно упрощается. Соответственно, данный материал будет посвящен различиям в моделировании истории между централизованным и децентрализованным системами управления версиями.
Читать полностью »

Мое первое знакомство с системой контроля версий было еще в школе. Это был Subversion. В то время меня очень впечатлила его сила и возможности. Но шло время. Были не очень приятные моменты с переименовыванием файлов, каталогов и прочее (да, да здравствует svn 1.5, 1.6 и его вечные папки .svn). И все бы продолжалось в том же духе, если бы однажды в компании не задумались о смене системы контроля версий. Все случилось неожиданно быстро и предо мной возник Mercurial. Пришлось почитать о его особенностях, поспрашивать советов бывалых и вот я уже сам помогал своим коллегам разобраться в поведении и работе нового инструмента. Чем дольше я знакомился с Hg, тем больше он мне нравился, точнее, нравился его децентрализованный подход к контролю версий, Subversion же неизбежно отходил на второй план.
Однако, на новом месте работы мне снова пришлось вспомнить о Subversion, что, честно сказать, меня не обрадовало. К счастью, это не было безоговорочной политикой компании и предложить альтернативу было вполне реально, особенно учитывая, что некоторые сотрудники предпочли Git и успешно с ней работают. Значит, дело за малым – наглядно показать, в чем же преимущества работы с децентрализованными системами контроля версий: Git или Mercurial, но, в силу моего личного опыта, рассказать я решил про Hg. Собственно, эта статья есть краткое содержание круглого стола, проведенного мной с целью сравнения и смены системы контроля версий.
Читать полностью »

Начиная с сегодняшнего для все сайты GitHub Pages переходят на новый домен: github.io. Это мера безопасности нацеленна на предотвращение CSRF атак на главный сервер — github.com. Если ваш сайт настроен, как «yoursite.com» вместо «yoursite.github.com» — изменения вас никак не затронут.
Если ваш сайт раньше располагался на домене «username.github.com», последующие запросы будут редиректиться на новый домен: «username.github.io».
C этого момента все сайты, размещенные на субдоменах github.com могут и должны расцениваться как официальные продукты GitHub.
Читать полностью »

Будучи поклонником программных продуктов для визуализации активности в репозиториях таких как code_swarm и gource. В один прекрасный день я был посещен музой, которая вдохновила меня создать онлайн сервис для визуализации статистики репозиториев с GitHub.
И сегодня хочу предоставить на ваш суд мой проект GitHub Visualizer (проект на GitHub).
Вот скринкаст для предварительного знакомства.

И не большая Gif'ка
image

Что использовано

Читать полностью »

В этой статье я хотел бы поделиться своими впечатлениями от использования Atlassian Bamboo — системы непрерывной интеграции от компании Atlassian. В Java-проекте, над которым мы работаем, изначально в качестве системы управления использовалась JIRA On Demand, т.е. облачная версия JIRA, установленная на серверах компании Atlassian. В определенный момент появилась необходимость внедрения системы непрерывной интеграции. Важным требованием при выборе такой системы была поддержка из коробки системы автоматической сборки Gradle. Подобному требованию удовлетворяло лишь несколько систем непрерывной интеграции: всем известный Jenkins, Jetbrains TeamCity и Atlassian Bamboo. Под катом изложено как это работает и почему же мы выбрали Atlassian Bamboo. Осторожно — много картинок!Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js