Mercurial (он же Hg) — весьма приятная распределенная система контроля версий (distributed VCS). Среди удобств DVCS вообще и Hg в частности можно особо выделить высокую гибкость. Репозиторий может называться как угодно, копироваться куда угодно, коммититься в продакшн по произвольным цепочкам (скажем, через QA или напрямую) и так далее.

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

Если два репозитория вложить один в другой, Mercurial будет рассматривать их изолированно. Команды, адресуемые внешнему репозиторию, не распространяются на вложенный. Но как же управляться с проектом, если он раздроблен на изолированные фрагменты — этакие пузырьки, один в другом? Или, другими словами, как нам за деревьями (репозиториями) увидеть лес (проект) и работать на его уровне? От мучений нас избавит ForestExtension — расширение для Mercurial. Этот Forest добавляет несколько команд, идентичных базовым, но учитывающих вложенность репозиториев.

Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).

Прим. переводчика: В этой статье я буду ис­поль­зо­вать ори­гиналь­ные анг­ло­языч­ные сокращения DVCS и DAG для обозначения расп­ре­делён­ных систем контроля версий (Distributed Version Control System — DVCS) и нап­равлен­ных ацикличных графов (Directed Acyclic Graph — DAG).

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

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

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

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

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

За последний месяц мне поступило три звонка, в которых звучали эти загадочные слова, и я был вынужден объяснять, как оно работает. Я глубоко убежден, что знаниями нужно делиться, — это верное средство от деградации. Потому, в меру своего понимания попробую объяснить широкой общественности, что же они значат. Итак, далее речь пойдёт о трёх устройствах TANDBERG для обеспечения видеосвязи: TMS, VCS Control и VCS ExpressWay.

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

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

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

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

В статье не будут рассмотрены различия между разными DVCS. Также не будет детально рассматриваться работа с git, по этой теме есть множество хороших источников, которые я приведу в конце статьи.

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

Чтобы управлять доступом можно использовать различные решения gitosys, gitolite, mercurial-server, но эти решения работают через SSH, что не всегда удобно (должен быть ключ). В добавок не хватает гибкости у подобных решений.

Основные требования:

• доступ по логину/паролю (HTTPS)
• контроль прав на чтение/запись
• публичный/приватный репозиторий
• управления всем через веб интерфейс
• все данные (информация о проекте и пользователях) должны храниться в базе (MySQL)

Для решения этой задачи сделал следующую систему…

Доброго времени суток!

Данная статья посвящена одной небольшой задачке – переносу репозитория вместе со всей историей с одной системы управления версиями в другую, а точнее – в SVN. Речь пойдёт об использовании бесплатной утилиты Importer for SVN от Palarion, с помощью которой можно мигрировать с CVS / PCVS / VSS / ClearCase / StarTeam / MKS на SVN, не потеряв при этом журнала изменений кода. В моём случае потребовалось перенести проекты из Borland StarTeam.

Почему было сказано «нет» StarTeam и «да» SVN? Сначала думал пропустить данный абзац во избежание холиваров. Но, пожалуй, без этого статья была бы лишена, скажем так, области определения. В моём случае отказаться от StarTeam вынудил уход человека, его внедрившего и администрировавшего. Пара дней безуспешных попыток заставить работать сервис под другой учётной записью породили мысль о том, что задача восстановления репозиториев из бэкапов станет ещё большим вызовом. Конечно, радиус кривизны рук можно было значительно увеличить спустя какое-то время. Но оно нам надо, спрашивается, когда есть бесплатный, до безобразия лёгкий в установке и поддержке SVN? Тем более что у меня было предостаточно опыта его использования на предыдущих местах работы, а все два с половиной разработчика находятся в одной комнате.

Одно препятствие – жаль было терять историю изменений. Сначала думали залить в SVN текущие версии, а историю смотреть в StarTeam, переведя его предварительно в read-only. Но, как говорится, это не наш метод. И непродолжительный гуглопоиск навёл на выше в суе помянутый Palarion Importer for SVN.

На сегодняшний день существуют два типа систем управления версиями: клиент-серверный и распределенный. Но несмотря на огромное различие между ними мы все-равно продолжаем использовать центральный сервер для синхронизации работы между участниками команды.
А что будет если в один прекрасный день центральный сервер сгорит?
Давайте это обсудим

С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

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

Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

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

Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty

Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер

Открываем страницу с SSH ключами и добавляем из буфера наш ключ

Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.

Устанавливаем и настраиваем msysgit

Какие системы контроля версий Вы используете (для собственных проектов и для работы)?

Приветствую вас, коллеги!

Относительно недавно здесь публиковался опрос по используемым системам контроля версий. Как и ожидалось, с большим отрывом победил Git, а Fossil даже не был включен в список, только в комментариях пару раз промелькнул. Поиск по Хабру показал, что здесь о Fossil практически ничего не писали. Поэтому я и решил опубликовать эту статью — тем более, что русскоязычная информация о Fossil крайне скудна и однообразна.

Продолжаем разговор о Fossil.

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

Предлагаю вашему вниманию перевод небольшой статьи из блога Armin Ronacher — автора Flask, Jinja2 и много чего еще. На этот раз он поделится своими мыслями о Git — распределенной системе управления версиями файлов.

Git для меня интересная тема. Впервые я попробовал использовать Git, когда там не было вообще никакой системы команд, а Cogito считался многообещающим проектом. Не могу сказать, что мне это понравилось, в то время я в основном пользовался SVN, и он полностью решал все мои задачи. Вскоре я познакомился с Mercurial, и это была любовь с первого взгляда, положившая начало долгому и позитивному опыту использования этой VCS (version control system), которая получила в моем лице преданного сторонника. Только в 2008 году я перешел на Git, и мне потребовалось несколько попыток, прежде чем я понял, что пора переносить на него мои репозитории.